On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
Andrei Alexandrescu <[email protected]> wrote:
Let me be more specific: BinaryHeap does not work like a range. It
_is_ a range. It implements all of a forward range's primitives with
the required semantics.
Is not anything that works like a range automatically a range?
Yah, just wanted to be precise.
But where should I put it then? I thought it would be even more
confusing if I put something in std.container that wait a minute, is
not a container.
How is it not a container? Because it uses a different container as a
back-end?
It does not implement the container primitives and is not a reference type.
Generally, a range with benefits (i.e. extra functions) is still a range
if it implements the required range primitives with the required
semantics.
So many containers are ranges, then.
There aren't because no container implements e.g. popFront().
And we will see this question for
any of those containers added to Phobos. Or we decide on some rules to
disambiguate between the two, and follow those.
There are already rules that disambiguate range operations from similar
container operations. For example a range defines popFront() whereas a
container defines removeFront().
I hold that a range is a view that does not change the underlying data,
and does not store all its data.
That makes an array a container, which I feel is correct. It may still
have range functionality, and thus be both, but it should be
categorized as a container first.
Are there other ranges that violate this definition?
The explanation goes as Steve puts it. A container has control over its
topology.
I agree that a BinaryHeap built on top of a container may ultimately
affect the topology of the container, which makes it unlike e.g. Take or
Chain. I could choose to disallow that and simply require that
BinaryHeap always works on top of a range, not a container. But I think
it's useful to have the growing functionality, and I don't think that
makes BinaryHeap hopelessly confusing.
Andrei
