On 05/19/2010 07:57 PM, Bill Baxter wrote:
On Wed, May 19, 2010 at 4:01 PM, Andrei Alexandrescu
<[email protected]> wrote:
My vision, in very brief, is to foster a federation of independent
containers abiding to identical names for similar functionality. Then a few
concept checks (a la std.range checks) can easily express what capabilities
a given client function needs from a container.
Destroy me :o).
So instead of STL's concept hierarchy, you have essentially concept
tags. Very Web 2.0. :-)
I agree that there doesn't seem to be any coding benefit to STL's
concepts being hierarchical. If you need a push_back(), you've got to
check for push_back(). The main benefit seems to be for documentation
purposes, allowing you to say things like "bidirectional_iterator has
this and that, plus everything in forward_iterator". But that could
easily be rephrased as "it has backward_iteration plus
forward_iteration" with two pages describing those two tags.
So I like the sound of it. But it seems actually a pretty small
departure from the STL approach, in practice.
Well in fact STL has a concept hierarchy for iterators (which D also has
for ranges), and a flat, unstructured approach to container.
I don't mind keeping what STL does if there's no good reason. One change
I do think is beneficial is making containers reference types by default.
Andrei
