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.
