[SAoC] Move semantics and STL containers

[Suleyman]

On Wednesday, 11 December 2019 at 17:48:24 UTC, bachmeier wrote:
>> [...]
>
> Okay. That's reasonable. Does v = a copy or can we reuse a.ptr 
> with your implementation? Keep in mind that I don't know much 
> about std::vector or the work you're doing.

If you pass it a slice then it has to copy, and the reason being 
is that  `vector!double` is short for `vector!(double, 
allocator!double)`, notice it has an allocator therefore it can't 
reuse the a pointer if the allocator is not the same.

Even if hypothetically there was no allocator problem then a move 
operation - which is what you've described as reusing the slice 
pointer - can only be done if the constructor/opAssign of the 
vector knows that the slice is an rvalue (for example an array 
literal is an rvalue, or the result of an explicit move operation 
is also an rvalue) and I don't know of any way to declare a slice 
of rvalues right now. I will add a slice of rvalues as a type to 
my rvalue ref implementation (which will be documented and 
announced with a DIP in the next milestone). I was hesitant at 
first to allow slices of rvalues, but after porting std::vector I 
came across various move strategies among which was move 
iterators and since used slices instead, I found that I couldn't 
declare a move construtor/opAssign for slices, and I didn't, this 
is one of the lacking parts right now in the array API of vector, 
if you pass a slice it always has to copy no matter what.