Can assumeSafeAppend() grab more and more capacity?

[Ali Çehreli via Digitalmars-d-learn]

On 06/06/2017 12:13 PM, Jesse Phillips wrote:
 > On Monday, 5 June 2017 at 23:17:46 UTC, Ali Çehreli wrote:
 >>     auto a = [ 1, 2, 3, 4 ];
 >>     auto b = a;
 >>
 >> Both of those slices have non-zero capacity yet one of them will be
 >> the lucky one to grab it. Such semantic issues make me unhappy. :-/
 >>
 >> Ali
 >
 > You have to remember that slices don't own their memory. So while
 > capacity show a guaranteed reserved memory, it is reserved for the
 > dynamic array the slice has a window into.
 >
 > Remove probably shouldn't try to reclaim capacity, while it is
 > destructive for any other slice, it shouldn't make string appending also
 > destructive.
 >
 > untested:
 >
 >      auto a = [ 1, 2, 3, 4 ];
 >      auto b = a[$-1, $];
 >      a.remove(2);
 >      assert(b == [4]);
 >      a ~= 6;
 >      assert(b == [4]);

Agreed.

The only issue remaining for me is the part that you've quoted: If we 
can trust capacity per spec, like we would trust after calling 
reserve(), then a and b in my code above are counter examples where both 
a and b have capacity initially but one of them will lose its capacity 
as soon as the other one gains an element.

Although I like the fact that the current semantics are more efficient 
(because capacity is given lazily), they conflict with the other part of 
the spec.

Ali