D array expansion and non-deterministic re-allocation

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el 19 de noviembre a las 17:13 me escribiste:
>> 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.
> 
> I don't think so, slices (a view over somebody elses memory, no appending)
> should be the lowest level abstraction.
> 
>> 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.
> 
> I don't. Current built-in arrays are both dynamic arrays and slices, which
> is what messes all up.

Well it also makes arrays/slices quite capable.

Right now they only have one problem (which different people ascribe a 
different gravity to) and are otherwise very expressive. Now think of 
this: the MRU solves a grave issue with slices. We haven't thought of 
that for years, and all of a sudden stomping is not an issue anymore. I 
wouldn't be in the least surprised if someone posts in this group 
tomorrow that they found a way to make ~= more predictable.

> But I'll drop the subject, once again, for the sake of... well, everybody
> ;)

I encourage you to further your point (while in understanding that your 
existing arguments and proposals have been understood). This is the best 
time to make a contribution to D's design.

We may as well undefine "~" or "~=" or both for arrays if there's enough 
arguments and evidence that it's a problem to keep them. When making 
proposals just keep in mind one important thing: with the context that 
you (all) have accumulated regarding this discussion, a lot of things 
seem very easy to understand, which are really weird when just starting 
with the language.

One other thing is that it's all tradeoffs; things that are "good" in 
all dimensions are in very short supply. With arrays, we may be in the 
position of choosing a solution that won't please everyone. The question 
right now is "which 5% of users you will disappoint". As for reviving 
T[new], I believe that, unless some new insight comes forward, 
practically that ship has sailed. That doesn't preclude defining a 
library type that is a more encapsulated array. Fortunately, that can be 
implemented using T[] because T[] is expressive enough :o).


Andrei