Jonathan M Davis Wrote:

> On Wednesday, December 01, 2010 14:32:12 bearophile wrote:
> > foobar:
> > > 1. static_cast:
> > >   a. Remove ALL implicit coercions inherited from c such as double ->
> > >   int, b. I don't see the need for an operator for conversions since
> > >   they can have different parameters, e.g.: - converting to string can
> > >   have formatting specified
> > >   - converting string to numeric types with optional base parameter
> > >   - converting integer to floating point specifies
> > >   round/floor/ceiling/etc..
> > > 
> > > 2. const_cast: should be a _separate_ operator in order to prevent removing const by mistake.
> > > 
> > >   const Base obj1 = new Derived();
> > >   auto obj2 = cast(Derived)(obj1); // oops: meant to only down cast
> > > 
> > > 3. dynamic_cast: the language should provide a down cast operator for OO. 4. reinterpret_cast: unsafe and should be restricted as much as possible (Not available in @safe code) maybe not provide it at all since it's implementable via union. A restricted library solution for when you really want to play with bits and bytes?
> > 
> > There are some ideas here, like the separation from const_cast, dynamic cast, and other casts. In past I too have asked for something similar, but I think Walter was not interested.
> > 
> > I guess the idea of having a single cast is to keep the language simple. But those _are_ different kinds of casts, they have different semantics. Lumping different semantics into the same syntax is not a good way to simplify a language, in my opinion. It just creates obscurity and maybe some other troubles too.
> 
> And how many programmers do you know who actually, really know the differences between the 4 C++ cast types. _I_'m not sure that _I_ know, and I've studied it. And honestly, in most cases - if not in _all_ cases - as far as I can tell, the compiler should be able to determine the correct cast type. So, forcing that on the programmer is just stupid. If you actually _need_ separate cast types, then we should have them, but if we can avoid that, we definitely should. I think that the fact that C++ has so many types of casts is horrible. I try and use them correctly, but I don't think that there are very many programmers (percentage- wise at least) who do. I know plenty of programmers who just use C-style casts everywhere.
> 
> - Jonathan M Davis

My suggestion is much simpler than c++. the _language_ needs only to provide two operators: down cast operator and const cast operator. interpret cast is a corner case that can also be implemented as a library utility. conversions can and should be done with regular D code (functions). which is not far from current D idioms (to!).

On Thursday, December 02, 2010 02:23:23 foobar wrote:
> My suggestion is much simpler than c++.
> the _language_ needs only to provide two operators:
> down cast operator and const cast operator.
> interpret cast is a corner case that can also be implemented as a library
> utility. conversions can and should be done with regular D code
> (functions). which is not far from current D idioms (to!).

Personally, I think that const_cast is _the_ most pointless cast operator of the lot. Simply cast, and if const is part of the new type and wasn't part of the old one, then it's adding const-ness. If const isn't part of the new type and it was part of the old one, then it's removing constness. Adding the extra complexity just to make sure that you didn't accidentally add or remove const seems to be totally overkill to me. And since casting away const in D is technically undefined behavior anyway, does it even make sense to add a specific operator for it?

- Jonathan M Davis

On 12/2/2010 10:35 AM, Jonathan M Davis wrote:
> On Thursday, December 02, 2010 02:23:23 foobar wrote:
>> My suggestion is much simpler than c++.
>> the _language_ needs only to provide two operators:
>> down cast operator and const cast operator.
>> interpret cast is a corner case that can also be implemented as a library
>> utility. conversions can and should be done with regular D code
>> (functions). which is not far from current D idioms (to!).
> 
> Personally, I think that const_cast is _the_ most pointless cast operator of the lot. Simply cast, and if const is part of the new type and wasn't part of the old one, then it's adding const-ness. If const isn't part of the new type and it was part of the old one, then it's removing constness. Adding the extra complexity just to make sure that you didn't accidentally add or remove const seems to be totally overkill to me. And since casting away const in D is technically undefined behavior anyway, does it even make sense to add a specific operator for it?
> 
> - Jonathan M Davis

The problem is that it's unsafe across type changes.  Consider:

  const T x;
  void foo(T);
  foo(cast(T)x);  // drop const, it happens to be safe for some reason

What happens when the type of x changes?  Finding all casts of x across all the code that might reference x is problematic.  When all you want to do is manipulate the constness, being forced to do so via repeating the type means your code is more fragile than it needs to be.

Later,
Brad