On Monday, 30 May 2016 13:52:20 MSK Andrzej Krzemienski wrote:
2016-05-30 11:29 GMT+02:00 Andrey Semashev
: I think that would be the best solution. Additionally, I would suggest moving the whole library to its own namespace (e.g. optionals). Then the tag in the library namespace would look more natural. For backward compatibility you could import the optional class template into boost namespace.
Hmm. Moving optional to a nested namespace has other benefits also: disabling unintended ADL.
Exactly.
But I can't see how I can be made to work for a tag like in_place.
If I put it also into a nested namespace and then do a:
namespace boost{ using nested::in_place }
It will still collide with the current in-place factories. Or did I misunderstand your suggestion?
No, I wasn't suggesting importing boost::optionals::in_place into boost. Only import what is currently considered API (i.e. the optional template; I don't think anything else qualifies as such). Also document the change and deprecate the imports so that people start porting to the nested namespace. You can remove the imports when you feel it's safe. This could also be done for boost::none as well for good measure.