RFC: naming for FrontTransversal and Transversal ranges

[Andrei Alexandrescu]

Robert Jacques wrote:
> On Wed, 29 Apr 2009 20:45:23 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at 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