D array expansion and non-deterministic re-allocation

[Bartosz Milewski]

Andrei Alexandrescu Wrote:

> Bartosz Milewski wrote:
> > Steven Schveighoffer Wrote:
> > 
> >> As long as the spec says changing length may expand the array to hold enough space, the optimizer can't, because the optimization would change the side effects of the function.  An optimizer should not change the outcome or side effects of a function.  It's not unheard of for an optimizer to eliminate important operations that it thinks are invalid, but in that case, it's a broken optimizer, I don't see why we would add this case.
> > 
> > This is all true for user-defined data types, but array is totally under compiler's control. What optimizations are acceptable depends only on the interpretation of the language spec. In particular the sequence
> > 
> > a.length -= 1;
> > a.length += 1;
> > 
> > as a whole does not result in stomping, so why would it be wrong to optimize it away? I claim it's perfectly legitimate. 
> 
> Yes, but this gets into optimizing sequences of complex operations, so 
> the question is one of expectancy. What if I insert something there:
> 
> a.length -= 1;
> writeln("Why oh why???");
> a.length += 1;
> 
> After all people don't ordinarily expect C++ compilers to optimize away
> 
> a.resize(a.size() - 1);
> a.resize(a.size() + 1);
> 
> Each function has some semantics and effects, and I don't know why we'd 
> want to get down the route that effects depend on the flow in which the 
> function gets called.
> 
> What is the example trying to accomplish?
> 

I'm trying to nail down the semantics. Here is the case where there provably is no stomping. If this can be optimized away then the language guarantee has to be formulated accordingly. Right now I don't know what to expect from the code I wrote. Is it a good substitute for duplicate or not? 

I get worried when the semantics of a very important and essential primitive--the array--is hard to explain and comprehend.