D array expansion and non-deterministic re-allocation

Bartosz Milewski bartosz-nospam at relisoft.com
Fri Nov 20 00:36:20 PST 2009


Andrei Alexandrescu Wrote:
> I think one aspect that tends to be forgotten is that built-in arrays 
> are the lowest abstraction - really just one small step above pointers. 
> Efficiency lost there is lost forever. That's why I consider the current 
> design adequate and the proposed designs less so.

Let's look at your proposal from a slightly different perspective. First of all, a conforming implementation is free to do the re-allocation on every append. There are no complexity requirements specified. 

The controversy stems from the fact that the spec deliberately leaves a window for certain optimizations that might result in the array being write-shared after the append. In that case the spec dictates certain restrictions that are expressed informally as no-stomping. BTW, we can't currently evaluate the proposal until no-stomping is formally defined.

Because of that, a program written for and tested on one conforming implementation may not work correctly on another, depending on what optimization strategy is picked. That will probably lead to implementations that use a compile-time switch to disable such optimizations. 

The bugs resulting from not understanding when write sharing is possible (and I'm afraid a lot of programmers will have problems following the spec in this area) will be subtle. They will also be "soft" (as opposed to "hard" bugs), and those are much harder to discover and track down. 

All these things have to be carefully weighed. We are in uncharted territory.



More information about the Digitalmars-d mailing list