The analogue of "fill-pointer" in D

[Ali Çehreli via Digitalmars-d-learn]

On 05/18/2015 11:19 AM, John Colvin wrote:> On Monday, 18 May 2015 at 
17:43:50 UTC, Ali Çehreli wrote:
 >> On 05/18/2015 05:26 AM, John Colvin wrote:
 >>> On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote:
 >>>> On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
 >>>>
 >>>>> No, afraid not. Function capacity is not an analogue of 
fill-pointers!
 >>>>
 >>>> It's exactly the same.
 >>>
 >>> But in D capacity is affected by other things.
 >>>
 >>> auto a = new int[20];
 >>> auto b = arr[0..10];
 >>> //can't now append to b without re-allocating or using 
assumeSafeAppend.
 >>
 >> Perfect opportunity to inject my newly-discovered issue with capacity:
 >>
 >> void main()
 >> {
 >>     auto a = new int[20];
 >>     foo(a);
 >>     //can't now append to a
 >> }
 >>
 >> void foo(const(int)[] p)
 >> {
 >>     p ~= 42;
 >> }
 >>
 >> Ali
 >
 > I don't understand what's counterintuitive here. Slices are just pointer
 > and length, everything else is global state.

Nothing counterintuitive. I have discovered recently that when there are 
multiple slices with equal length, capacity is shared until one of them 
appends, in which case that first appender wins the capacity.

I have always known about non-stomping and why this has to be so. What 
was new to me is the initial suspense when we don't know who will win 
the capacity. Just news to me.

In all other cases where there is one longest slice (like your example), 
then there is only one owner of capacity.

Ali