[range] #11202: boost.sort header conflicts with boost.range header
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?
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. - Jim
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
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
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 <boost/range/algorithm/sort.hpp> (in module range): from graph: <boost/detail/algorithm.hpp> <boost/graph/vf2_sub_graph_iso.hpp> -----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 _______________________________________________ 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 <boost/range/algorithm/sort.hpp> (in module range):
from graph: <boost/detail/algorithm.hpp> <boost/graph/vf2_sub_graph_iso.hpp>
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
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).
On Wed, 29 Aug 2018 at 11:20, Peter Dimov via Boost <boost@lists.boost.org> 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 Wed, Aug 29, 2018 at 11:22 AM Edward Diener via Boost <boost@lists.boost.org> wrote:
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:: .
It's not pretty, but it sounds reasonable to me. Do you have a counterproposal?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2 September 2018 at 03:21, Steven Ross via Boost <boost@lists.boost.org> 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 Sun, 2 Sep 2018 at 17:18, Mathias Gaunard via Boost < boost@lists.boost.org> wrote:
Rename the "sort" library to something else.
boost::foo seems appropriate for a sort library, alternatives are boost::bar or boost::baz.
"sortlib" is very bad, but other names could be found.
libsort is already better, as adding lib to the name of a lib seems to be the habit on nix. 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*
On 9/2/2018 10:09 AM, Mathias Gaunard via Boost wrote:
On 2 September 2018 at 03:21, Steven Ross via Boost <boost@lists.boost.org> 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.
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 <boost@lists.boost.org> 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! G
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 <boost@lists.boost.org> 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.
On 3 September 2018 10:22, Andrey Semashev via Boost wrote:
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 <boost@lists.boost.org> 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.
Native speakers are not always the best people to make these decisions, as they're more like to use idioms or obscure language. :-) However, https://www.google.com/search?q=sort+meaning gives me: Sort, noun 2. [Computing] "the arrangement of data in a prescribed sequence." as well as the verb, "arrange systematically in groups; separate according to type." But boost::sorting works too! G
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> 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.
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.
On Mon, 3 Sep 2018 at 16:21, Peter Dimov via Boost <boost@lists.boost.org> 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*
On Mon, Sep 3, 2018 at 10:09 AM degski via Boost <boost@lists.boost.org> wrote:
On Mon, 3 Sep 2018 at 16:21, Peter Dimov via Boost <boost@lists.boost.org> 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.
Right. It would be ridiculous to rename an entire library because of a single using declaration that conflicts with the boost namespace policy, and basing things on the contents of std:: is silly; how many people do both "using boost" and "using std"? Such broad using declarations hide what people are actually using. Removing the using range::sort is simple and will only require people specifically using it to specify a longer name. I'm not advocating eliminating all the using declarations in the boost namespace range has.
participants (10)
-
Andrey Semashev -
degski -
Edward Diener -
Gareth.Sylvester-Bradley＠sony.com -
Groke, Paul -
James E. King III -
Mathias Gaunard -
Neil Groves -
Peter Dimov -
Steven Ross