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

[Andrei Alexandrescu]

On 06/09/2010 10:37 AM, Don wrote:
> Andrei Alexandrescu wrote:
>> On 06/09/2010 07:57 AM, Michel Fortin wrote:
>>> On 2010-06-08 17:41:22 -0400, "Simen kjaeraas" <simen.kjaras at gmail.com>
>>> said:
>>>
>>>> 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.
>>>
>>> And if you were accustomed to the STL, you'd just look for a binary heap
>>> header to include instead of trying to philosophize about which category
>>> of things it fits best. That's why I suggested "std.binaryheap" earlier.
>>> (Could be "std.binheap" if you want it short.)
>>
>> I don't think this will scale. There are quite a few data structures
>> out there, I'm afraid we'll have too many modules too soon.
>>
>> Andrei
>
> On the other hand, I don't think we want a 5Mb module, either. There's a
> very large number of potential containers, once you include all the
> esoteric ones.
>
> (std.algorithm has the same problem, of course).
> It's a difficult tradeoff. I hope you're able to come up with a
> reasonable rationale.

I'm not sure what's the best approach. Best I can think of is by 
category, e.g. all sequences go in std.sequence, all trees go in 
std.tree, all hashes go in std.hash and so on. Since heaps are trees 
they may be in std.tree. But then there are quite a few heap kinds out 
there (binary, Fibonacci, binomial, soft) so perhaps std.heap is deserved.

Andrei