Re: [boost] [review] [heap] Summary

Subject: Re: [boost] [review] [heap] Summary
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-06-20 14:56:04

> This is of course not a very large foundation on which to make such a
> decision. Nor is the vote particular clear.
>
> I didn't cast a vote, but I will be /extremely/ unhappy with having
> a library where this is not addressed:

Like I said in the summary, comments received during the review did
not indicate any fundamental problems with the design or
implementation of the library, and many people seemed to be satisfied
with it. Although there weren't a lot of formal votes, I felt that
there was enough discussion for me to make an informed decision. My
vote was based on a difference in design philosophy, but in the end, I
didn't consider that to be a sufficient reason to reject the library.

The lack of participation, especially when it came to voting, was discouraging.

> If drop-in support for other types of containers is not added,
> the library is a lot less useful for me (and many others). There is plenty
> of motivation for having this feature, and it is dead-easy to implement as
> well.
>
> So /please/ add this to the list of required fixes that must be done before
> inclusion is possible.

No, I will not add this to the list of requirements. I considered this
suggestion very carefully when writing my evaluation and again when
preparing the summary and ultimately decided that trying to shoehorn
this requirement into the existing framework was not the best approach
for providing the feature. Phil's suggestion of implementing heap
algorithms on ranges lends itself to a more natural solution to this
requirement. I strongly encourage Tim to consider this strategy in
future revisions of the library.

Andrew