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

[Daniel Keep]

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

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

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.

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

  -- Daniel