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

[Michel Fortin]

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). T[U] is a 
reference to an associative array. 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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/