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

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Sat, Aug 25, 2018 at 10:31 PM Steven Ross via Boost <
[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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 <
> [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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: [hidden email]
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 <
> [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
> 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: [hidden email]
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 <
> [hidden email]> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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: [hidden email]
> 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 <
>> [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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).


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Wed, 29 Aug 2018 at 11:20, Peter Dimov via Boost <[hidden email]>
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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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:: .


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Wed, Aug 29, 2018 at 11:22 AM Edward Diener via Boost
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 2 September 2018 at 03:21, Steven Ross via Boost <[hidden email]>
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Sun, 2 Sep 2018 at 17:18, Mathias Gaunard via Boost <
[hidden email]> 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*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/2/2018 10:09 AM, Mathias Gaunard via Boost wrote:

> On 2 September 2018 at 03:21, Steven Ross via Boost <[hidden email]>
> 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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 <[hidden email]> 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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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 <[hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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 <[hidden email]> 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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Mon, 3 Sep 2018 at 16:21, Peter Dimov via Boost <[hidden email]>
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*

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