Why not move cast to the standard library?

Jeremie Pelletier jeremiep at gmail.com
Thu Sep 24 12:16:27 PDT 2009


downs wrote:
> Jeremie Pelletier wrote:
>> grauzone wrote:
>>> Andrei Alexandrescu wrote:
>>>> downs wrote:
>>>>> Andrei Alexandrescu wrote:
>>>>>> downs wrote:
>>>>>>> With all the neat template tricks we have in 2.0, and since we're
>>>>>>> widely redefining the syntax anyway, why not deprecate the current
>>>>>>> cast syntax and move it into object.d as a library function?
>>>>>>>
>>>>>>> So instead of cast(Foo) bar; you would say cast!Foo(bar); .. save
>>>>>>> on a
>>>>>>> keyword and demonstrate language power at the same time.
>>>>>>>
>>>>>>> What sez ye?
>>>>>> What would the implementation look like?
>>>>>>
>>>>>> Andrei
>>>>> Unions, and LOTS of static ifs. :)
>>>> Unions won't work for casting class objects and interfaces because
>>>> those do pointer adjustments. I think cast must be a primitive.
>>> When casting interfaces and objects, the primitive cast just calls
>>> into runtime (functions like _d_dynamic_cast etc.). I don't see a
>>> reason why cast implemented as templated function couldn't call those
>>> runtime functions directly.
>>>
>>>> Andrei
>> What about cast(int) or cast(string) and whatnot then? You'd have
>> cast!A(B) for classes and cast(int) for values, that would be backwards.
>>
>> Jeremie
> 
> What about cast!int could _not_ be done as a function?

I don't want to call into functions for simple value casts. If I want 
safe casts I use to!int. It may get inlined in release code, but think 
of the debug overhead it would generate.

The current way is great as it is, cast() for straightforward unsafe 
casting and to!(T)() for safe casting. This is exactly what makes D 
attractive to me, the choice between safe and unsafe alternatives.



More information about the Digitalmars-d mailing list