2016-05-30 12:57 GMT+02:00 Andrey Semashev
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
namespace would look more natural. For backward compatibility you could import
On Monday, 30 May 2016 13:52:20 MSK Andrzej Krzemienski wrote: library 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.
But wouldn't that be a bit of an inconvenience that a "vocabulary type" as common as Optional should be used with additional long namespace prefix (or users required to type a using declaration themselves everywhere)? Regards, &rzej