On Wednesday, 19 April 2017 at 08:52:45 UTC, kinke wrote:
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov
wrote:
But it is always assumed that a value can be moved.
It's not just assumed, it's a key requirement for structs in D,
as the compiler can move stuff automatically this way (making a
bitcopy and then eliding the postblit ctor for the new instance
and the destructor for the moved-from instance).
That is quite a different concept to C++, where a (non-elided)
special move ctor is required, moved-from instances need to be
reset so that their (non-elided) destructor doesn't free
moved-from resources etc.
That's not quite correct. Copy elision in C++ also elides copy
and move ctors and dtor.
Move ctors aren't a requirement, they *can* be defined to
override default move semantics, or deleted to disable move
construction.
That is concerning optimizations performed by the compiler.
Library move(), both in C++ and in D, cannot elide the
destructor, as the value already exists.
But move() in C++ and D is indeed different. In C++ it's just a
cast, and it is up to the programmer to redefine the semantics if
needed, or disable it. In D, we're not allowed to do either. I'm
only proposing to relax the restriction in terms of disabling
move, not introduce move ctors into D.
