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

[Robert Jacques]

On Sat, 25 Apr 2009 16:16:07 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> 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;
>> }
>
> Yes, but that way you take the owner (i.e. the memory block) completely  
> out of the picture. It would help to give the owner an identity.
>
> Andrei

1) In what way would it help to give the owner an identity?

2) How does reference counting arrays "take the owner completely out of  
the picture"? Isn't this simply a switch from single ownership to shared  
ownership?