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

[Simen kjaeraas]

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> Instead of assuming that I'm simultaneously retard(ed) and stubborn

I'm sorry, that was not my intention.

> I wrote BinaryHeap out of necessity. The necessity was to solve the  
> selection problem (see topN, topNIndex in std.algorithm) and to  
> implement n-way merge (see std.algorithm.nWayUnion, I think I'll rename  
> it to nWayMerge).
>
> In all these cases, there was no necessity for defining a heap as a  
> container; instead, using it as a means to add structure over an  
> existing range were sufficient.
>
> If I defined the heap as a container, there would be need for one extra  
> allocation and also extra indirections to ensure reference semantics. I  
> wanted to avoid all that.

Now this is exactly what I wanted! Thank you. Sorry we had to fight to
get there. :p


> It's a good point. I agree it would make sense to define a binary heap  
> container in addition to a binary heap range. I'm only weary that they  
> don't have very clean means to reuse code, so we'll end up with some  
> unpleasant implementation internals. I guess I'll just have to do that.

I fear that this will also lead to confusion. "What? Two binheaps? What
do they need that for?" Basically, the binheap range is a heapifying
range, yes?

So to me, it seems to make sense to have std.range.heapify, and
std.container.binheap.

-- 
Simen