RFC: naming for FrontTransversal and Transversal ranges

[Denis Koroskin]

On Thu, 30 Apr 2009 23:57:17 +0400, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> 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

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.