Decision on container design

[SHOO]

(2011/01/29 3:31), Andrei Alexandrescu wrote:
> 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.
>
>
> Andrei

 >1, 2
I think that it is a good policy.
There is hardly the superiority that a containers are structs. :-)

In the first place I had doubt towards treating structs as classes 
(OOP). When I use it by such a way, the lack of the default constructor 
is fatal.

 >3, 4
If speed is accompanied, the sealing up is useful, but if it is late, 
there are many unnecessary cases. Because it is thought that a lot of 
repetition access to the element and life cycles occurs in the case of a 
container, handling it by the element unit should be high-performance. 
In addition, for usability, a thing of simple behavior is preferable 
rather than a complicated thing.
However, on the other hand, the design that wrong use is impossible 
should be considered enough.