Re: [boost] Boost.Operators issue: polluting namespace of caller through argument-dependent lookup

Subject: Re: [boost] Boost.Operators issue: polluting namespace of caller through argument-dependent lookup
From: Daniel Frey (d.frey_at_[hidden])
Date: 2016-01-20 11:41:17

> On 20.01.2016, at 00:43, John M. Dlugosz <mpbecey7gu_at_[hidden]> wrote:
> 
> On 1/18/2016 1:11 PM, Andrey Semashev wrote:
>> On 2016-01-18 21:03, Daniel Frey wrote:
>>>> On 17.01.2016, at 10:51, John M. Dlugosz <mpbecey7gu_at_[hidden]>
>>>> wrote:
>>>> 
>>>> The use of make_shared is finding boost::make_shared as well as
>>>> std::make_shared.  The program doesn't use boost::shared_ptr and
>>>> shouldn't need to know about it.
>>> 
>>> This can not be simply “fixed” as it is quite an old and established
>>> interface. What about the people that actually rely on ADL to kick in
>>> to find their unqualified call of make_shared?
>> 
>> Given that there is BOOST_NO_OPERATORS_IN_NAMESPACE, I don't think that the addition of
>> the boost namespace to ADL was ever intended. I would rather see this fixed and the code
>> that relies on this side effect broken (with the appropriate note in the release notes
>> and the advice to use namespace qualification to resolve the problem).
>> 
> It already varies with the version of Boost!  And with the selected headers being pulled in by other code.  So it already is a wild card that might work in some places and not others.

It won’t vary when you are doing it on purpose, you’d include the necessary headers explicitly instead of relying on some side-effect. Only when you are using unqualified lookup and you don’t expect this, it might change with the version of Boost.

> make_shared (or any other pre-standard library) is not related to the Operators feature, and people shouldn't count on it interacting in an undocumented way.  And it doesn't really: it depends on what else is included.

In a way it makes library collections like Boost harder and I still think you should use qualified lookup in your specific case, but as I already said in another mail I’m willing to fix it. I just need to figure out where to commit and merge stuff as the last time I worked on it we were still using svn and the branching model was different. I hope to be able to find the time somewhere in the next days.

Regards,
Daniel