RFC on range design for D2

[Oskar Linde]

Andrei Alexandrescu wrote:
> 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.

I'm very glad you share my thoughts on ~=. The current D T[] is a tool 
that has been stuffed with too many concepts.

Arrays and slices are two fundamentally different concepts that T[] 
actually manage to capture impressively well, but unfortunately not 
fully. And it is the last bit that makes the puzzle complicated.

One of the biggest differences between an array and a slice lies in the 
ownership of the data. And as far as I see it, arrays are conceptually 
better implemented as reference types, while slices are a natural value 
type.

So by removing ~= from T[], T[] becomes a pure slice type.

This is all the old T[new] discussion once again, but with the gained 
insight that instead of T[new] one could just as well use a pure library 
type.

-- 
Oskar