Jeremie Pelletier wrote: > downs wrote: >> Jeremie Pelletier wrote: >>> 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. >> >> What debug overhead? >> >> With current casts, all the logic is in the compiler - where you can't >> get at it. Moving it into the library can only make this better. >> >> There is nothing about cast that I can see that requires dedicated >> compiler assistance. >> >> Furthermore, consider it a testcase - if a trivial function like that >> isn't inlined, _something_ is wrong :) > > Compile with -debug -unittest -g and you get no inlines whatsoever, even > const values aren't inlined, when I run such an executable in windbg the > code cursor actually goes to the declaration of enums and other constants. > > A lot of casts are just type reinterpretations, with a few semantics > behind float to int conversions. I wouldn't give away the convenience of > cast() to force everything through to!(T)(). I use cast() for most cases > where I don't need anything special, and to!(T)() when I need some > specific semantics. It also makes such cases much easier to notice when > reading code.
Good argument. Thanks.