std.container and classes

[Jesse Phillips]

On Sat, 17 Dec 2011 17:31:46 -0600, Andrei Alexandrescu wrote:

> The second decision is classes vs. structs. Walter correctly pointed out
> that the obvious choice for defining a reference type in D - whether the
> type is momonorphic or polymorphic - is making it a class. If containers
> aren't classes, the reasoning went, it means we took a wrong step
> somewhere; it might mean our flagship abstraction for reference types is
> not suitable for, well, defining a reference type.

This is an interesting reasoning to go with class. Which is similar to 
what you end up saying here:

> One fear I have is that people would be curious,
> look at the implementation of std.container, and be like "so am I
> expected to do all this to define a robust type"? I start to think that
> the right answer to that is to improve library support for good
> reference counted types, and define reference counted struct containers
> that are deterministic.

I'm not really sure the answer, but here are some thoughts.

There is interest in having reference counting, and making it easy. There 
was a question on SO about how to make a reference counted object. I gave 
it my best shot answering having never done it myself. It isn't very 
straight forward and I think people will expect to use it similar to 
auto_prt. And considering how similar each wrapped object is, I think D 
can pull it off.

http://stackoverflow.com/questions/4632355/making-a-reference-counted-
object-in-d-using-refcountedt

So building a reference counted container type probably shouldn't be a 
challenge in D (or I should say it should be a goal to make it not a 
challenge). For example, it might be as simple as, a build a value 
container which you then expose wrapped with RefCounted!T

alias RefCounted!ContainerImp Container;

But as to whether this should be what is implemented in the standard 
library, I don't know. You make mention of custom allocators and such. Is 
this interest going to be of benefit, or is it just something people are 
use to having from C++? If it makes sense to have such then the 
containers should support it. Don't classes allow for custom allocators? 
Is there a reason that can't be used? Do we need to improve on that?