Immovable types

[Stanislav Blinov via Digitalmars-d]

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.