On 1/28/11 3:05 PM, Michel Fortin wrote:
On 2011-01-28 13:31:58 -0500, Andrei Alexandrescu
<seewebsiteforem...@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
