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

[Robert Jacques]

On Sat, 25 Apr 2009 21:14:28 -0400, Daniel Keep  
<daniel.keep.lists at gmail.com> wrote:
> Andrei Alexandrescu 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
>
> I've got a few problems understanding this thread.
>
> 1. What exactly do you mean by "genuine container type"?  That says to
> me there's some ISO standard or something arrays don't conform to.  I
> saw earlier you specify the lack of a capacity field; is that really it?
>
>    If so, why not call it a capacity-aware array (or capacitive array  
> :P).

 From a Model-View-Container standpoint, D's arrays mix both View and  
Container. Many think this is a good thing, but there is an argument for  
separating the views (slices) from the container (arrays). The whole  
capacity thing is separate from this issue and exists because 1) it's  
fixed in a free-list based allocator. 2) it's somewhat slow to query from  
the GC and 3) concatenating arrays, mainly when building strings, does it  
a lot.
P.S. Great names.

> 2. I don't see why you want these to have value semantics.  What's the
> motivation here.  Note that "because we need it" isn't a valid answer; a
> link to an explanation would be great, if one exists.  :)

It hasn't been explained so far. (Although there are some arguments for  
more general application of value semantics in older threads)

> 3. I'm really uncomfortable with the idea that the semantics of slices
> changes when you switch off the GC.  That means you have a valid program
> before, you throw -gc, and suddenly you get inscrutable crashes.

Actually, I'm pretty sure Andrei is proposing changing the semantics for  
both GC and no GC.

> As for the names, maybe we've got this backwards.  What about these:
>
> T[]      -- a freshly created array
> T[..]    -- a slice of an array
> T[U]     -- a freshly created associative array
> T[U..]   -- a slice of an associative array
>
> Otherwise, creating a new array would be (new T[new]) which looks
> stupid.  That, or it's (new T[x]) and the result type is (T[new]) which
> is inconsistent with every other type in the language.
>
> Also, this means static arrays stay as T[n].
>
> On another topic, you mentioned that (using your notation again) T[new]
> would have four words: begin, end (but I liked length! :( ),
> end-of-capacity and refcount*.  Could you pull a COM trick and stick the
> capacity and refcount out the front of the array data?
>
>   [ ? ] [ 4 ] [ 1 ] [ 2 ] [...] [...]
>     ^     ^     ^           ^
>     |     |     |           |
>     |     |   begin        end
>     |  capacity
>  refcount
>
> That allows T[new] to stay 8 bytes, and it also avoids needing a second
> allocation for the refcount (which should have the same lifetime as the
> array itself).

Or alternatively, both slices and arrays could store a pointer to the  
(refount, capacity) so you wouldn't need separate types.