Container hierarchy vs. container types

[Jonathan M Davis]

Andrei Alexandrescu wrote:


> (b) Pass by reference is more natural for containers than pass by value.

I concur with this. It rarely makes sense to outright copy containers, and 
when you do, you're explicitly looking to do so. If a container were a 
struct, then returning it from a function would be expensive. And it could 
get really messy trying to have one container as an element in another - 
particularly if you can't get a reference to the element in the container. 
You'd have to copy it out of the container, modify it, and copy it back in 
again. That's way too much unnecessary copying. And it would be easy to 
think that after you'd changed the element after getting it out of the 
container that it had changed the one in the container when you hadn't.

Container!(Container!(E)) cont;
...
auto element = cont.get(x);
element.add(someValue);
//With a class, the element in the container would now be altered.

vs

Container!(Container!(E)) cont;
...
auto element = cont.get(x); //this involves a copy
element.add(someValue);
cont.set(x, element); //this involves a copy

Now, by getting at the elements of a container by reference, that reduces 
the problem, but generally speaking, it makes no sense to be copying 
containers, and it's expensive to do so. I'd vote to just make them final 
classes. You gain the efficiency of inlining and have reference semantics 
which is really what typically makes sense for containers. If you want it 
copied, you can clone it or construct a new one with the elements of the 
first one. I really don't see what would be gained by making a container a 
struct.

- Jonathan M Davis