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

[Andrei Alexandrescu]

Robert Jacques wrote:
> 1) In what way would it help to give the owner an identity?

For example, on an implementation that doesn't want gc, they'd need the 
owner for deterministic destruction.

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]".

Makes sense?


Andrei