Vinnie Falco wrote:
However I have been informed that the criteria for accepting a library into Boost something more along these lines:
* That the library is useful, and * Boost is better off with the library than without
The second bullet should be * Boost is better off with the library than without, _in the long term_ That is, it's fine to object to acceptance on the basis that this will prevent a better library being accepted in the future. Of course, this argument is based on speculation and hypotheticals, and as such does not carry as much weight as arguments based on the here and now, or arguments rooted in the specific and concrete. Also, there are several more implicit bullets that basically say that the library should be defect-free in implementation and usability, that it has adequate documentation, that it actually builds on popular compilers, that it has enough test coverage, that the design is in line with best $CURRENT_YEAR practices, etc etc