D array expansion and non-deterministic re-allocation

[Steven Schveighoffer]

On Thu, 19 Nov 2009 17:58:15 -0500, Bartosz Milewski  
<bartosz-nospam at relisoft.com> wrote:

> Steven Schveighoffer Wrote:
>
>> > In fact, even after reading 4.1.9 I don't know what to expect in some
>> > cases. Here's an example:
>> >
>> > int[] a = [0];
>> > auto b = a;
>> > a ~= 1;
>> > b ~= 2;
>> > What is a[1]?
>> >
>> > Is this considered "stomping" and requiring a re-allocation?
>>
>> a[1] would be 1 if an MRU cache was introduced.  This is exactly the  
>> sort
>> of problem that the MRU cache is supposed to solve.
>>
>> What should happen is:
>>
>> a ~= 1 should allocate in place because its parameters were in the MRU
>> cache.
>> b ~= 1 should reallocate because the a~=1 should have removed its
>> parameters from the MRU cache.
>>
>
> Notice that you are using particular implementation detail (MRU cache)  
> to explain the semantics of D arrays. There is a very important  
> distinction between language specification and compiler implementation.  
> Andrei already had to go pretty deep into implementation to describe  
> arrays and slices: You can't define D arrays without talking about  
> shared buffers and memory allocation. I don't think including the  
> description of the MRU cache in the language specification is the right  
> solution. But I'm afraid an abstract definition of "stomping" might turn  
> out to be quite non-trivial.

I haven't yet read all the other posts, so someone else may already have  
pointed this out but...

Having an MRU cache makes it so you *don't* have to explain its semantics  
(or stomping).  Currently there is a paragraph in the spec (complete with  
example) talking about how stomping can occur, so you can just remove that  
part.  There is no need to talk about the MRU cache when talking about  
arrays, that's an implementation detail.  I was pointing it out because  
you are already used to the current bad implementation :)  I wouldn't even  
bring up the MRU cache in the book or the spec.  You just say that you can  
append to an array and it may make a copy of the data if necessary.  It's  
just like realloc, except safer.

-Steve