Decision on container design

[Andrei Alexandrescu]

On 1/28/11 3:05 PM, Michel Fortin wrote:
> On 2011-01-28 13:31:58 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> Today after work I plan to start making one pass through
>> std.container. After having thought of things for a long time, my
>> conclusions are as follows:
>>
>> 1. Containers will be classes.
>>
>> 2. Most of the methods in existing containers will be final. It's up
>> to the container to make a method final or not.
>>
>> 3. Containers and their ranges decide whether they give away
>> references to their objects. Sealing is a great idea but it makes
>> everybody's life too complicated. I'll defer sealing to future
>> improvements in the language and/or the reflection subsystem.
>>
>> 4. Containers will assume that objects are cheap to copy so they won't
>> worry about moving primitives.
>>
>> Any showstoppers, please share.
>
> Not my preferred choices (especially #1), but having containers in
> Phobos will certainly be an improvement over not having them. So go ahead!

Well if you brought forth some strong argument I'm all ears. What I see 
for now is that struct containers are just difficult to implement and 
need to have carefully explained semantics, whereas a lot of people know 
how classes behave from day one.

> About #4, it'd be nice to have the containers use move semantics when
> possible even if they fallback to (cheap) copy semantic when move isn't
> available. That way, if you have a type which is moveable but not
> copyable you can still put it in a container. Does that makes sense?

That's what I did up until now. It is tantamount to defining a bunch of 
methods (aliases or not) that add to the interface that the user must 
absorb, but that are seldom useful. It just seems that the entire move 
paraphernalia doesn't lift its weight.


Andrei