BinaryHeap is a range so it goes in std.range. Agree?

[Simen kjaeraas]

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
>> Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

>>> 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.

So it is not a container because you chose not to make it a container.

> There are already rules that disambiguate range operations from similar  
> container operations. For example a range defines popFront() whereas a  
> container defines removeFront().

And my point is that removeFront() is popFront() with a different name,
so many containers could be considered ranges with mutated member
functions. :p But we're arguing semantics.

> 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.

To me, this makes it a container.

Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and thus
check std.container. If it was not there, I would use the search function
to find it. I can invent reasons, but it's mostly grounded in learned
names and categories.

-- 
Simen