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

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Jun 8 09:26:19 PDT 2010


On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
> Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> 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


More information about the Digitalmars-d mailing list