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.
