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

[Robert Jacques]

On Sat, 25 Apr 2009 18:04:32 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

Why is a single owner needed 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).

What is wrong with reference counting arrays just like other objects?  
(which is what I've been proposing)

Also, I see a major logical problem with your proposal:
Given     A single owner is required for deterministic destruction.
Then      The array's owner is responsible for the deterministic  
destruction.
Therefore When the array's owner goes out of scope, it must destruct the  
array.
But Then  How does a function return an array?

Your original post mentioned value semantics, but that results in a lot of  
needless allocation and copying.

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

While separating hashes and ranges is important, it seems orthogonal to  
the topic at hand.

> Makes sense?

Yes and no. What I wanted was some high-level reason why have T[new] and  
T[] was fundamentally better than only having T[]. What I got was a low  
level assertion that they are needed to do -nogc. However, since earlier  
in this thread I provided a counter example, i.e. reference counted  
arrays, your assertion stands as false. And a language change shouldn't be  
based on a faulty assumption.