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

[Christopher Wright]

Robert Jacques wrote:
> 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.

Simple solution: put the array definition in object.d and try 
implementing arrays with reference counting or manual memory management.

I think stored slices break manual memory management, even with a 
dedicated slice type; but they should work just fine with refcounting. 
If you don't want to change the language, object.Array will have to 
implement the logic for slices and for allocated arrays. It's a bit 
ugly, and it makes the Array type larger. Also, Array's reference count 
would need to be accessed by reference.