2. Nothing prevent usage of the library. It's accessible. And in this particular case I noticed several support request in users ML
While I agree that this is technically true, in the commercial world the politics matter -- and being an 'add-in' boost library makes it difficult to handle. I also believe it limits seriously the audience that will look at the library because my perception is that most boost users don't mess with the sandbox or CVS -- they use the releases and that's it.
Filesystem is another evolving library -- it solves real problems for many current users, but it doesn't do everything people want. Many of the changes are usage and user driven as Beman evolves the library interfaces. Some of the eventual changes are issues that were known at the time of the review. Just as another example, I
I really believe we need to remedy this situation. I would love to use BOOST_FOREACH in my work projects, but end up writing my own think
boost.threads needs a full do over, but that doesn't make it any less useful for those that can make use of the library as it is and boost would be lesser for it's absence.
Much of this library future has to do with the nature of the author. One of my unstated evaluation criteria is the 'behavior' of the library author. The author must understand the domain, be ready to take criticism with grace, and move the work forward. If I didn't think Andreas is willing and up to
I believe in both above examples there were no major unresolved issues revealed during review. Fixing issues is natural part of library lifecycle whatever big changes involved. this
task I would have voted to reject...
It's your call. I did not follow the discussion that close.
In fact, 98% of the time when I'm writing a program I could care less about the traits template parameter and the other failings of std::string.
Just grep in boost and see in how name places libraries adding this parameter. And you (and I and vast majority of C++ community) never need it.
BTW, I don't think I've seen a proposal that identifies and eliminates all the std::string issues -- I suspect that's because it's very difficult to balance the entire design space for strings in a single interface.
For some time now I think we need boost::string. I hope upcoming reviews will cover this area (at least partially).
Anyway, while I think there are interesting directions that can be pursued to expand the contribution base via the sandbox, we would need significant work, in my opinion, to pursue these. And, in fact, perhaps we would want this to be a different organization from boost to make it clear that these aren't reviewed boost libraries.
As usual we just need volunteers to do the job ;) Gennadiy