RFC on range design for D2

[Andrei Alexandrescu]

Sean Kelly wrote:
> This would be easy to fix by making arrays / slices fatter (by adding a 
> capacity field, for example), but I'm still not convinced that's the 
> right thing to do.  However, it may well be preferable to eliminating 
> appending completely.  The obvious alternative would be either to 
> resurrect head const (not gonna happen) or to make append always 
> reallocation (not at all ideal).

I couldn't imagine it put any better. Maybe time has come for starting 
to look into a good solution for this problem. The way things are now, 
~= muddles the clean territory that slices cover.

Consider we define "unowned" arrays are arrays as allocated by new T[n]. 
They are "unowned" because no entity controls them except the garbage 
collector, which by definition recycles them when it's sure you couldn't 
tell.

An "owned" array would be something like a scope variable or an 
up-and-coming BlockArray!(T) with a destructor.

Slices are beautiful for iterating owned and unowned arrays just as 
well. You can have the slice refer to any range of any array no problem. 
Calling a ~ b creates a new, unowned array containing their 
concatenation. Assigning a = new T[n]; binds a to a fresh unowned array. 
And so on.

And all of a sudden we step on a kaka in this beautiful garden. Under 
very special, undetectable circumstances, a range becomes Hitler, 
annexes an adjacent range, and starts walking all over it. Sigh.


Andrei