D array expansion and non-deterministic re-allocation

[dsimcha]

== Quote from Bartosz Milewski (bartosz-nospam at relisoft.com)'s article
> 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.

Face it, D is a close to the metal language.  Any attempt to define the spec at a
purely abstract level without reference to any implementation details, and without
leaving certain details implementation defined is absurd.  I think people need to
face the fact that you can't have close-to-the-metal flexibility and performance
and at the same time far-from-the-metal strict separation of specification from
implementation details.