D array expansion and non-deterministic re-allocation

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> dsimcha, el 19 de noviembre a las 23:21 me escribiste:
>> Face it, D is a close to the metal language.  Any attempt to define the spec at a
>> purely abstract level without reference to any implementation details, and without
>> leaving certain details implementation defined is absurd.  I think people need to
>> face the fact that you can't have close-to-the-metal flexibility and performance
>> and at the same time far-from-the-metal strict separation of specification from
>> implementation details.
> 
> Yes, but I think this is a place where you are doing early optimization at
> the expense of usability. You can always do the slice-thinguie yourself if
> you are that needed for speed that you can't afford an extra indirection
> when using an array (which will be the only overhead if T[new] were
> implemented as a pure reference type).
> 
> I think the cost here in terms of usability if far higher than the little
> performance you loose, specially when you can overcome the issue for those
> weird cases where you need it.

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.

In other words: you can build a more convenient facility on top of T[], 
but you couldn't build a more efficient facility on top of a convenient 
one. I think D made the right choice with built-in arrays.


Andrei