Re: [boost] [optional] using name boost::in_place -- need your opinion/advice

Subject: Re: [boost] [optional] using name boost::in_place -- need your opinion/advice
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2016-05-30 07:05:25

2016-05-30 12:57 GMT+02:00 Andrey Semashev <andrey.semashev_at_[hidden]>:

> On Monday, 30 May 2016 13:52:20 MSK Andrzej Krzemienski wrote:
> > 2016-05-30 11:29 GMT+02:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
> > >
> > > 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.
>

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