== Quote from Bartosz Milewski (bartosz-nos...@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.
