D array expansion and non-deterministic re-allocation

[Bartosz Milewski]

Walter Bright 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.
> 
> The optimizer is free to change around implementation-defined-behavior 
> and undefined-behavior. For defined-behavior, it can change things 
> around as long as the observer cannot observe a change.
> 
> > This point brought up is a non-issue, an optimizer that changes the
> > outcome/side effects of a function is a broken optimizer, end of
> > story.
> 
> It can within the constraints of defined-behavior.

So the real question is, is extension defined in terms of re-allocation or in terms of stomping. In the former case, the compiler should not optimize, because re-allocation is the expected side effect. In the latter case, it can eliminate the code, because what counts is the absence of stomping.