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

[Unknown W. Brackets]

The only downside to this is, it's a Bad Thing to have the size of an 
array be different between GC's, but I think it's probably not entirely 
avoidable.

But, I really think it's the only good way to do it, imho.  Maybe the 
exact implementation is different, but creating a new type just seems 
even messier... the beauty of slices in D is that they're Not Different 
(TM.)

-[Unknown]


Robert Jacques wrote:
> On Sat, 25 Apr 2009 09:07:52 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
>> It looks we can't make it with only T[]. We need a genuine container 
>> type, and T[new] was suggested. It would probably have value semantics.
>>
>> T[U] seems to have the same problem. If T[U] is the range, then how do 
>> you call the container?
>>
>> If we follow through with a no-garbage-collected option for the core 
>> types, then we also need to distinguish between a slice and its 
>> container. The fact that we (almost) got away with T[] being at the 
>> same time the container and the slice was that the garbage collector 
>> would collect all unused slices.
>>
>>
>> Andrei
> 
> No, it's perfectly possible to have T[] be the same type for the 
> container and the slice with reference counting instead of a full GC. 
> All you need to do is store a pointer to the memory block's node. Then 
> it's trivial to 1) get the capacity and 2) increase / decrease the 
> reference count. You could even add an 'allocated length' parameter to 
> the node, so you'd avoid some of the slicing bugs in the current 
> implementation.
> 
> struct T[] {
>     T*     ptr;
>     size_t length;
>     void*  memory_block;
> }