Article about problems & suggestions for D 2.0

[Jonathan M Davis]

On Monday, August 29, 2011 13:35 Benjamin Thaut wrote:
> I hoped for a little bit more feedback about the article itself.
> Especially about the move constructor I suggested. Does anyone see a
> need for this, or is it just me?

Honestly, I find the fact that you're writing code which relies on the address 
of a variable on the stack a bit scary. Normally, that is a _bad_ idea. Now, 
you're obviously doing something quite abnormal, so it may be a good idea in 
your case, but you're definitely not doing something which your average 
programmer is going to need to do. And the fact that structs can be moved by 
having their bits copied around is a definite boon for efficiency. Adding move 
constructors would definitely complicate things. If there were enough use 
cases for them, then they may be worth adding, but at this point, the compiler 
definitely relies on the fact that it can move a struct without affecting it, 
so any code which relies on a struct _not_ moving is likely to be broken. The 
ramifications of adding move constructors are likely far from trivial.

Personally, I'd argue that it doesn't make any more sense to expect that a 
struct's location have _anything_ to do with its value, and that if you want 
to rely on its location, then you need to put it in a location that you can 
rely on. If anything, I'd argue that your structs should just have a variable 
identifying them if you want to have them be uniquely identifiable, but I 
don't really understand what you're doing.

Certainly, for the common case, adding move constructors is a needless 
complication, and I'd _very_ leery of the ramifications of the compiler not 
being able to rely on a move having the bits stay absolutely identical (and a 
move constructor would make it possible for the struct's state to change 
completely instead of really being a move). It's not necessarily completely 
unreasonable, but you appear to have found what I would expect to be a _very_ 
abnormal use-case.

- Jonathan M Davis