Re: [boost] [range] #11202: boost.sort header conflicts with boost.range header

Subject: Re: [boost] [range] #11202: boost.sort header conflicts with boost.range header
From: Neil Groves (neilgroves_at_[hidden])
Date: 2018-08-29 11:20:22

On Wed, 29 Aug 2018 at 11:20, Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> 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
>