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

[Jonathan M Davis]

Michel Fortin wrote:

> Personally I'd draw the line like this: a module should contain
> functions and types which are either tied in their implementation or
> which their use are correlated (if you use this thing you'll likely
> need this other one).
> 
> For instance, a tree set and a tree map are almost the same, so they're
> good candidates to put together in a module (std.tree?). A linked list
> and an array are totally independent in implementation, and the need
> for one doesn't correlate with the need for another, so there's no
> reason to put them in the same module; they thus belong to separate
> modules.
> 
> This "correlation in usage" rule should reduce the number of modules
> you need to import while also minimizing the number of symbols, the
> code size, and the dependencies of each module. What do you think?
> 

I'd expect that to lead to module explosion. It wouldn't be as bad as 
importing each class individually as typically happens in Java, but it would 
mean a lot more modules. It can certainly quickly lead to something close a 
module per container. I don't, personally, see much downside to throwing all 
of the containers in one module except that that's a lot to sort through 
when looking for a container documentation-wise. They definitely shouldn't 
be clashing with each other in any way, and ideally, you wouldn't be writing 
any code which clashed with them either since they'd be standard.

Breaking up larger modules like std.algorithm and std.container isn't 
necessarily a bad idea, but it definitely should be done in a manner which 
avoids module explosion.

Personally, I'd much prefer something closer to importing the entire 
standard library with one import than having to import each individual class 
one by one.

- Jonathan M Davis