D array expansion and non-deterministic re-allocation

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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

I'd be inclined to support the MRU (and even implement it) iff:

1.  We still get a good library array type that pulls out all the stops to make
appending efficient.  (I'm putting my effort where my mouth is and working on
writing one pursuant to my ideas about combining it with uniqueness right now,
actually).

2.  We state in the documentation that ~= on slices is a convenience that isn't
terribly efficient and recommend that people that care more about performance than
simplicity use the library type for their serious array building, especially for
large arrays.