Kinds of containers

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 21 October 2015 at 16:36:46 UTC, Brad Anderson 
wrote:
> On Wednesday, 21 October 2015 at 11:05:12 UTC, Andrei 
> Alexandrescu wrote:
> [snip]
>> 2. Reference containers.
>>
>> These have classic reference semantics (à la Java). 
>> Internally, they may be implemented either as class objects or 
>> as reference counted structs.
>>
>> They're by default mutable. Qualifiers should apply to them 
>> gracefully.
>>
>> 3. Eager value containers.
>>
>> These are STL-style. Somewhat surprisingly I think these are 
>> the worst of the pack; they expensively duplicate at the drop 
>> of a hat and need to be carefully passed around by reference 
>> lest performance silently drops. Nevertheless, when used as 
>> members inside other data structures value semantics might be 
>> the appropriate choice. Also, thinking of them as values often 
>> makes code simpler.
>>
>> By default eager value containers are mutable. They should 
>> support immutable and const meaningfully.
>
> Having both reference and value semantics for containers would 
> be great. I don't understand why reference semantics would be 
> implemented by the container themselves though. Why not a 
> general purpose RC! (or RefCounted! if the current design is 
> deemed sufficient) that can apply to anything, including 
> containers? Then you'd only need to implement the value 
> semantic containers (and maybe throw in some RC version aliases 
> to promote the use of the RC versions so the option isn't 
> overlooked). It seems kind of crazy that anything in D that 
> wants to be reference counted would need to implement the logic 
> themselves.
>
> If there are performance advantages (I haven't thought of any 
> but perhaps there are) to bake the RC right into the container 
> it might also be possible to use DbI take advantage of it in 
> RC! when appropriate.
>
> It just seems so wrong to implement reference counting dozens 
> of times independently, especially when that means implementing 
> all the containers twice too.

If we had value type containers and reference type containers, I 
would assume that they would at least share implementation, and 
maybe the reference types would just be wrappers around the value 
types. However, I completely fail to understand why you'd ever 
want a container that was a value type. In my experience, it's 
very error-prone and adds no value. It just makes it too easy to 
accidentally copy a container, and it can be pretty easy to have 
an iterator, range, etc. referring to a container that's already 
been destroyed (similar to having a dynamic array referring to a 
static array that's left scope). As long as the containers have a 
dup method (or whatever we call it) so that they can be copied 
when you do want to copy them, I would think that that was more 
than enough. What do you get with a value type container that you 
consider better than a reference type? It's not like it lives on 
the stack as a value type. Most of the container's guts are on 
the heap regardless.

- Jonathan M Davis