On Wed, 29 Aug 2018 at 11:20, Peter Dimov via Boost
Edward Diener wrote:
The right thing would be for the sort library to change its boost::sort namespace name to something else, like boost::sortlib, so as not to conflict with range's boost::sort algorithm. In general there should be no boost:: namespace names with the same name as a std:: algorithm as this will conflict with range's mimicking the standard algorithms with a range instead of iterators.
This made sense in the past when we put everything in boost:: but I'm not sure it makes sense today. Our current de-facto policy is one namespace per library matching its name, and nothing else in boost::. This is the only approach that scales.
So I'd say that it's Range that needs to yield rather than Sort (which does everything by the book).
I am happy to yield and your point is a reasonable one. I do not anticipate that altering the namespaces for all of Boost.Range (it currently uses boost, boost::range, boost::adaptors) to be the least friction for our users. Perhaps we just put my sort functions into boost::range and don't bring them out and it's just a wart of the library. Putting all of Boost.Range into boost::range would, of course, mean even boost::begin becomes boost::range::begin. Would you want boost::adaptors namespace to go into boost::range::adaptors? To me this does all make sense given the guidelines that we have now, but the upheaval for users appears, to me, to be a much bigger cost than the initial problem. While the new approach makes sense, the current state of Boost.Range in the boost namespace I would anticipate would be a very limited issue going forward since other new libraries would be going into namespaces under boost. I think that making sort an exception and not bringing it into the boost namespace is a reasonable short-term fix, that I assume my users will be less irritated by. I am happy to make a change to Boost.Range. If users are happy with the large rework of their code to have Boost.Range alter the namespace then I would be happy to do this work also. It is a tricky decision, perhaps bringing old code into line with new guidelines is a priority over breaking interfaces. That's a tough call I see both sides. I am reluctant to push work onto existing users of Boost.Range. Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost