FWIW, boostdep says that boost/range/algorithm.hpp is not used anywhere in Boost. -----Original Message----- From: Edward Diener via Boost Sent: Wednesday, August 29, 2018 05:38 To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] [range] #11202: boost.sort header conflicts with boost.range header On 8/28/2018 10:16 PM, James E. King III via Boost wrote:

On Sat, Aug 25, 2018 at 10:31 PM Steven Ross via Boost < boost@lists.boost.org> wrote:

...

https://svn.boost.org/trac10/ticket/11202 has been sitting for years. The "using range::sort" causing the namespace pollution needs to be deleted, and then everything depending on that inside boost needs to be fixed. This will break people dependent on the namespace pollution, but that's the only way to clean it up. Is anyone willing to take on this cleanup?

Is there a good way to identify cross-library dependency breakages in situations like this so they can be fixed?

Thanks for bringing attention to this.

If you do not get any satisfactory answer from maintainers of the libraries mentioned then let us know, so the CMT can reach out and if needed assume responsibility for maintaining any abandoned work

Boost.Range does the same thing with all its algorithms, lifting their names into the boost namespace. I gather this was done to mimic the std:: algorithms dealing with iterators and with the idea that no other library would use the name of standard algorithms within the boost namespace for any purpose. I am sorry that this was not caught when Boost.Sort was initially reviewed, especially as I was the review manager. .

- Jim

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 8/29/2018 5:24 AM, Peter Dimov via Boost wrote:

...

FWIW, boostdep says that boost/range/algorithm.hpp is not used anywhere in Boost.

Oh that's just the umbrella header. Well, boost/range/algorithm/sort.hpp is used here:

Inclusion report for (in module range):

   from graph:              

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. I realize that Boost.Sort changing its namespace to boost::sortlib, for instance, is a breaking change but I think it is the right thing to be done as it would simply require users of Boost.Sort to change the namespace name in their code in for subsequent Boost releases.

-----Original Message----- From: Edward Diener via Boost Sent: Wednesday, August 29, 2018 05:38 To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] [range] #11202: boost.sort header conflicts with boost.range header

On 8/28/2018 10:16 PM, James E. King III via Boost wrote:

...

On Sat, Aug 25, 2018 at 10:31 PM Steven Ross via Boost < boost@lists.boost.org> wrote:

...

https://svn.boost.org/trac10/ticket/11202 has been sitting for years. The "using range::sort" causing the namespace pollution needs to be deleted, and then everything depending on that inside boost needs to be fixed.  This will break people dependent on the namespace pollution, but that's the only way to clean it up.  Is anyone willing to take on this cleanup?

Is there a good way to identify cross-library dependency breakages in situations like this so they can be fixed?

Thanks for bringing attention to this.

If you do not get any satisfactory answer from maintainers of the libraries mentioned then let us know, so the CMT can reach out and if needed assume responsibility for maintaining any abandoned work

Boost.Range does the same thing with all its algorithms, lifting their names into the boost namespace. I gather this was done to mimic the std:: algorithms dealing with iterators and with the idea that no other library would use the name of standard algorithms within the boost namespace for any purpose. I am sorry that this was not caught when Boost.Sort was initially reviewed, especially as I was the review manager.

.

...

- Jim

On Wed, 29 Aug 2018 at 11:20, Peter Dimov via Boost 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

On 8/29/2018 7:53 AM, Peter Dimov via Boost wrote:

Neil Groves wrote:

...

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.

That's what I had in mind, yes.

I think it is a bad idea to make an exception for boost::range::sort when all the other range algorithms are directly in boost:: .

On 2 September 2018 at 03:21, Steven Ross via Boost wrote:

...

I think it is a bad idea to make an exception for boost::range::sort when all the other range algorithms are directly in boost:: .

It's not pretty, but it sounds reasonable to me. Do you have a counterproposal?

Rename the "sort" library to something else. "sortlib" is very bad, but other names could be found.

On 9/2/2018 10:09 AM, Mathias Gaunard via Boost wrote:

On 2 September 2018 at 03:21, Steven Ross via Boost wrote:

...

...

I think it is a bad idea to make an exception for boost::range::sort when all the other range algorithms are directly in boost:: .

It's not pretty, but it sounds reasonable to me. Do you have a counterproposal?

Rename the "sort" library to something else. "sortlib" is very bad, but other names could be found.

I was just suggesting a change in the namespace name to something else. It can still be called the sort library, even if the namespace is not boost::sort. Although it is discouraged I think allowing function, template, and class names directly in the boost namespace should be allowed when those names mimic std:: names, but with Boost functionality. I think Boost should avoid as much as possible using namespace names which are the same as std:: functions, templates, and classes.

On 09/03/18 11:42, Gareth Sylvester-Bradley via Boost wrote:

At 2 Sep 2018 18:48, Edward Diener via Boost wrote:

...

On 9/2/2018 10:09 AM, Mathias Gaunard via Boost wrote:

...

On 2 September 2018 at 03:21, Steven Ross via Boost wrote:

...

...

I think it is a bad idea to make an exception for boost::range::sort when all the other range algorithms are directly in boost:: .

It's not pretty, but it sounds reasonable to me. Do you have a counterproposal?

Rename the "sort" library to something else. "sortlib" is very bad, but other names could be found.

I was just suggesting a change in the namespace name to something else. It can still be called the sort library, even if the namespace is not boost::sort.

Would it be appropriate to adopt the strategy of Boost.Tuple, whose namespace is boost::tuples, and use boost::sorts as the library namespace?

The naming consistency guidelines say:

* The library's primary namespace (in parent ::boost) is given that same name, except when there's a component with that name (e.g., boost::tuple), in which case the namespace name is pluralized. For example, ::boost::filesystem.

That's maybe not quite the case here, but it's not horrible!

I'm not a native speaker, but I don't think "sort", in the meaning the library puts in it, has a plural form as it is a verb. "Sorting" might be an alternative.

-----Original Message----- From: Boost On Behalf Of Andrey Semashev via Boost Sent: Montag, 3. September 2018 11:22 Subject: Re: [boost] [range] #11202: boost.sort header conflicts with boost.range header

I'm not a native speaker, but I don't think "sort", in the meaning the library puts in it, has a plural form as it is a verb. "Sorting" might be an alternative.

Boost.Move has a similar situation and uses namespace boost::movelib. Therefor I think the originally suggestion, boost::sortlib, isn't such a bad idea. I don't really *like* the name, but it would be consistent with Boost.Move. That aside, I think boost::sorting is a good name.

On Mon, 3 Sep 2018 at 16:21, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

Although it is discouraged I think allowing function, template, and class names directly in the boost namespace should be allowed when those names mimic std:: names, but with Boost functionality. I think Boost should avoid as much as possible using namespace names which are the same as std:: functions, templates, and classes.

This is impractical. New names appear in std:: every three years, it's not possible to predict in advance whether a library name will match a standard identifier. It worked in the past when C++98 was all we had, it doesn't work now.

I think that as hardly any Boost library that was adopted in the standard actually complies (sometimes more, sometimes less and sometimes just different) with the standard, the boost namespace should be enough warning that we are talking about something else than whatever is in the standard. So boost should simply do what it thinks is best from its perspective, namespace-wise. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*