[SAoC] Move semantics and STL containers

[Andrei Alexandrescu]

On 10/23/19 1:19 PM, Suleyman wrote:
> Week 5:
> 
> Start of milestone 2.
> 
> * Move constructor semantic implemented based on the work on rvalue ref.
> * A default move constructor is generated if one or more members of a 
> struct have  move constructor.
> * The move opAssign implemented as well.
> * A `@move` attribute with an accompanying `__move()` intrinsic was 
> added as an alternative to rvalue ref.
> 
> Usage example:
> 
> 1. with rvalue ref
> 
> compile with the compiler switch `-preview=rvalueattribute`.
> ```
> struct S
> {
>      static char[] result;
>      this(@rvalue ref inout S) inout { result ~= "Mc"; }
>      void opAssign(@rvalue ref inout S) inout { result ~= "Ma"; }
> }
> 
> unittest
> {
>      S a;
>      S b = cast(@rvalue ref)a;
>      a = cast(@rvalue ref)b;
>      assert(S.result == "McMa");
> }
> ```
> 
> 2. with the `@move` attribute
> 
> compile with the compiler switch `-preview=moveattribute`.
> ```
> struct S
> {
>      static char[] result;
>      this(ref inout S) @move inout { result ~= "Mc"; }
>      void opAssign(ref inout S) @move inout { result ~= "Ma"; }
> }
> 
> unittest
> {
>      S a;
>      S b = __move(a);
>      a = __move(b);
>      assert(S.result == "McMa");
> }
> ```
> 
> Note: the implementation is not ready yet for things like internal 
> pointers, some interaction with the codegen is needed to eliminate the 
> remaining blits that still exist.

As far as I understand this is a major language change that proceeded 
without a known plan, and of which likelihood to be accepted is doubtful.

This work must definitely be coordinated to the other related projects - 
binding rvalues to ref, move constructors, perfect forwarding, DIP 1014. 
We can't have different people work independently on their own vision of 
features that overlap 80%.

Don't we risk adding this to our growing list of projects that people 
invest vast amounts of talent and work, just to abandon them?