Is opCast need, we have to!

Jesse Phillips jessekphillips+D at gmail.com
Thu Dec 2 07:32:28 PST 2010


foobar Wrote:


> > >   - 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..
> > 
> > This was kind of my point, to! already specifies how to generically (an important part) to other types. And opCast overrides everything (which I don't wish to claim is incorrect, just asking).
> > 
> 
> I don't follow as to how this is important to have a generic interface. Can I specify parameters for conversion with to! as in my examples? 
> I'd appreciate an example 

Oops, sorry, though I don't see why it can't be specified in to!.

> > > 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
> > 
> > I think to! should be changed such that this would be a ConvException.
> 
> This should not even compile. a run-time exception is better than current D but is still very weak.

See my bug report, http://d.puremagic.com/issues/show_bug.cgi?id=5307

After making it a runtime error, I made it just not compile. (Error message sucks though.)

> > > 3. dynamic_cast: the language should provide a down cast operator for OO. 
> > 
> > Then the example above is invalid, though still valid when casting const double to int...
> 
> a down cast should _only_ perform dynamic down casts in the OO sense. so:
> Base foo = new Derived; 
> Derived bar = downCast(foo); // compiles. performed at run-time
> 
> [const] double -> int is not a down cast, it is a conversion.

I was referring to the need for const_cast
 
> > Maybe std.math.floor should return an int, since they are implicitly converted to real...
> > 
> > > and also:
> > > int x = ??; // some number
> > > double y = x; //compile-time error
> > > double z = double(x); // explicit
> > 
> > Other than overflow, which isn't fixed if made explicit, I don't see an issue with it being implicit.
> 
> besides the overflow issue you have mentioned, I also don't want special cases. No implicit conversions should be applied equally everywhere. 

Then be explicit in all of _your_ code. That won't stop others from using implicit conversion, but you can just assume they are of the same type and be fine.



More information about the Digitalmars-d mailing list