bearophile wrote: > This comes from a recent small discussion on the D.learn newsgroup, and > from an answer by Daniel Keep: > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=18915 > > There are many possible kinds of casts in D: > - To interpret a sequence of bits in a different way, like a uint as a > float, a double as a fixed array of two ints, a fixed array of 8 bytes > into a fixed array of 2 ints, etc, with no need of an intermediate union > definition (And sometimes I want to convert a class reference to a > different class, currently you can do it with: cast(Foo)cast(Void*)bar). - > To perform a safe dynamic cast between two objects, that can return null. > This operation is a bit slow. - To perform a conversion, for example from > double to an int, with truncation. In future I can even want a way to tell > the compiler how to perform such N to M conversions, so I can convert an > int to its string equivalent, etc. - To perform a cast between two arrays, > where I want to convert (reinterpret) each item, using a true conversion. > - Maybe there are other kinds of casting (like turning an immutable into a > mutable, an impure into a pure, arg!, etc). > > Conflating so much different things in the same cast() syntax is less > unsafe and is less flexible. > > In C++ there are 4+1 kinds of casts, they add some complexity. Maybe in D2 > just two different casts can be enough: - A cast that works at compile > time only, with no run time penality (the first and last type in my list). > - A cast that has to perform some operations at run time (the other kinds > of casts in my list). > > I think this is an important enough thing for D2, and it's not a backwards > compatible change, it's not an additive change if you want to do it well > (otherwise if you want to follow the route used by C++ of just > discouraging the usage of the old C cast it can be an additive change, but > it increases the language complexity). > > If you want to do this in a good way, you can for example use: > - static_cast() or scast() for the purely compile-time ones. > - dcast() or dynamic_cast(), or just cast() for the run-time ones. Such > casts are a bit safer, so they can use a shorter name. > > Another good thing is to make the cast semantics more tidy, aligning the > effects of the casts done on an array literal with the effect of the same > cast done on a run-time array (I think they are a bit different now). > > Bye, > bearophile
C++ is the only language that I'm aware of which has multiple types of casts, and I don't think that it really adds anything of benefit. C-style casts are, of course, unsafe, but that doesn't mean that you need a bucket- load of cast types in order to be safe. Languages like Java and C# manage safe casting with only one type of cast. Two is definitely better than four, but I question that we really need more than one. Can't the compiler figure out which cast is supposed to be used in a given situation and deal with it internally? Having multiple casts just confuses things (certainly, I don't think that I know anyone who fully understands the C++ casts). Really, casts should be quite rare in code anyway. And as much as I'd like to avoid performance penalties, I'd prefer a performance penalty in the rare case when I have to cast rather than having to worry about whether I or anyone else on a project that I'm working on is using the various cast types correctly. In most C++ code that I've seen, people don't bother to use anything other than a c-style cast unless they specifically need one of the C++ casts for a safety reason - like using dynamic_cast to check whether you can safely cast to a particular type. In almost all cases, they just use a c-style cast. I think that it would be a huge mistake for D to have more than one type of cast. And honestly, I would have thought that the compiler would be able to figure out the correct cast type internally. And if it can't, should you really be doing that cast in the first place? I say keep the current single cast type and leave it at that. - Jonathan M Davis
