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