Arrays of noncopyables/Invalid memory operation

[Matt Elkins via Digitalmars-d-learn]

On Friday, 19 February 2016 at 01:30:13 UTC, H. S. Teoh wrote:
> Suppose the array gets moved sometime after i=500 because it 
> ran out of space in the current memory location.  Since there 
> is another slice middleSlice pointing at the old data, it's not 
> just a matter of *moving* the elements over to the new 
> location; they have to be *copied* over so that there are now 
> two copies of the original elements -- the GC doesn't know 
> whether func may try to access the original elements through 
> middleSlice, so it cannot just move them. Only when middleSlice 
> goes out of scope, can the old elements be destructed.
>
> So we see that when an array is grown, the elements cannot 
> simply be moved to the new location; we must make copies of 
> them, otherwise any slice of the old data will become invalid. 
> So after an array is moved, there will be two copies of data, 
> and if the original elements are unreferenced after all, the GC 
> will call the dtors when it runs the next collection cycle.  
> Then when the new elements become unreferenced, the dtors will 
> be called again at the following collection cycle, on the new 
> copies of the elements.

So it seems that the conclusion is that it is indeed unsafe to 
store non-copyable objects in an array which might grow (though 
it would be nice if attempting to do so was a compiler error, 
like it is with std.container.Array). I've starting creating a 
custom "Vector" type with value semantics which is move-aware, so 
hopefully that will address my needs.

Thanks for all the help, folks!