If T[new] is the container for T[], then what is the container for T[U]?

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-04-25 18:04:32 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> Again, slices could be conflated with arrays mainly because the gc 
>> took care of the litter left after rebinding slices. If you want to 
>> offer the option to do without a gc, then arrays and slices (= ranges) 
>> must be separate entities. Then you hold on to the arrays and pass 
>> slices around. When you destroy the arrays, the slices originating 
>> from them become invalid (which can be checked or not).
>>
>> With hashes it's even more interesting. We need two types: the hash 
>> and the hash range that crawls over that hash. Right now they are 
>> conflated into one V[K]. If we want to define a range crawling over a 
>> hash (and consequently do away with opApply) we'd need the range to 
>> store a little stack of breadcrumbs so the range knows how to iterate. 
>> So definitely there must be two entities. Traditionally we've been 
>> using V[K] both as a range and as a container, but the usage so far 
>> was closer to a range (I think without being sure). So one issue is to 
>> find a good type literal to express "type for which the corresponding 
>> range is V[K]".
> 
> You say there must be two entities. But the two entities already exist, 
> only the container is stored by reference. T[] is a reference to a 
> portion of a fixed-size array (static array or heap array).

Yah, and the question is where is the entire array.

> T[U] is a 
> reference to an associative array.

Yah, and the question is where is the range that the associative array 
uses for iteration.

> If you could call "new" and "delete" 
> on these two types to delete the referenced container, or if the 
> container were reference-counted, you wouldn't need a garbage collector. 
> It's pretty much the same as for classes in fact.

It might be wise to make those types values, not references.


Andrei