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?