On Thu, 30 Apr 2009 23:57:17 +0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Robert Jacques wrote:
On Wed, 29 Apr 2009 20:45:23 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
It has become increasingly clear we'll need to support arrays in
addition to slices.
No, Andrei it hasn't. A detailed paragraph (or more) explaining we you
think so should be included in the full RFC.
There are several converging pieces of evidence. Each can be debated in
separation, yet together they make for a rather strong case.
People have complained about the incredibly bad, unsafe, and slow
behavior of appending. Even before the considerable recent slowdown of
~=, there were speed concerns. Worse than that, the completely weird
behavior of slices that grow to stomp on other slices cannot be defended.
The idiom:
array.length = n;
array.length = 0;
// append to array up to n...
is rather disingenuous and looks odd to the casual reader.
As predicted by the "range theory" which predicates that a range will
never grow, only shrink, slices should always shrink. Growing is a
foreign operation for a slice. This is a big problem that goes beyond a
need for purity or cleanliness - it's just terrible to have a slice
stomping around, and then uncontrollably being rebound elsewhere and so
on. People pass slices into functions, functions modify them and also
append to them, and depending on the phase of the moon, some updates are
being seen in the caller.
So people have defined various types (such as ArrayCreator or
ArrayAppender or whatnot) that take care of that aspect. But really what
we're looking at is an Array type.
Another issue is that we can get (partly) away with disowned slices
because of the garbage collector: whenever a slice is to be rebound,
whatever chunk it was bound to is left behind and will be duly
collected. If, however, we want to support other programming disciplines
that exercise stricter control over memory, the "parent" arrays must
become an explicit type that code can keep around and manipulate
directly.
A design that has one container type and several slice types that crawl
it in various ways is very compelling, and I think it will be a huge
selling point for D. It would be odd, not natural, to have arrays as a
singularly distinct container that is in fact its own range. We get away
with container == range for arrays partly because arrays are a simple
structure, but that only blurs thinking and understanding of more
complex containers. In fact, ranges do predict that any attempt to grow
a range will cause topological issues in the owning container; that's
why SList wisely (IMHO :o)) includes a template parameter that tells
whether its topology is fixed or flexible.
(Last but not least, .NET has arrays and slices. D's slices that
actually have an array testis mesh real bad with .NET because in .NET
you can't have a disowned slice.)
Andrei
I'm all for introducing Array type, but what would using it look like? Is it a
plain Array!(T), or is there any shortcut planned. One of the selling points of
slices is their ease of use. T[] is freaking awesome!
I also would like to see what would Phobos look like after introducing Arrays.
A good thing is that it's quite easy start implementing Array right now - all
you need is to disallow ~ and ~= operations on slices. Then, go through Phobos
code and see what got broken and start fixing it using newly written Array
template (compiler doesn't have to know anything about it). I beleve it will
become immediately clear whether D Arrays should be a reference or value type.
