D array expansion and non-deterministic re-allocation

[Andrei Alexandrescu]

Bartosz Milewski wrote:
> 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?

The answer is very simple, and it is present in the book. I have also 
repeated it here. Appending to an array may or may not terminate an 
existing sharing relationship, and it never initiates a sharing 
relationship. Assigning a larger length is equivalent to appending a 
number of default-initialized values. There is nothing difficult here, 
although convoluted examples can be created that compound "if"s in 
complex interactions.

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

We have a couple of dozens of other things to worry about. There are 
deadlines and many other more important and more urgent things to work 
on. The primitive is not important and not essential. It's a primitive, 
and like all primitives, it can be used to create better abstractions. 
UDP is a primitive protocol with few guarantees, but TCP is implemented 
on top of it to provide the guarantees. Simple, efficient primitives are 
a defensible choice.


Andrei