Boost logo

Boost :

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

2016-05-30 12:04 GMT+02:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>

> Andrzej,
> On 2016-05-30 17:47, Andrzej Krzemienski wrote:
>> ...
>> I am trying to make boost::optional resemble std::optional (where it is
>> reasonably easy to achieve). std::optional has this nice and useful
>> "placement" constructor:
>> std::optional<std::mutex> m {std::in_place};
>> std::in_place is a tag type, that instructs std::optional to create an
>> object using placement-new syntax, from the provided arguments (zero in
>> the
>> example), without incurring any move construction.
>> ...
> To me the situation sounds quite concerning as I'd expect boost libs to
> extend std counterparts, i.e. I suspect many people would expect boost::foo
> = std::foo + something-else-useful functionally-wise. That is, I'd
> personally expect the migration from boost::foo to std::foo to be a simple
> renaming matter (if I did not use extra boost functionality).
> The situation with in-place factories sounds like a diversion and you seem
> to suggest (if I've got it right) to move even further.

There seems to be some misunderstanding here. Indeed, there is currently a
gap between std::optional and boost::optional: we have a name
std::in_place, which is a tag, and we have a name boost::in_place, which is
something different. More, boost::in_place is not part of Boost.Optional
library: it is in Boost Utility Library.

I am exploring the possibility of closing the gap between two optionals, I
just don't see how to do it without breaking the backwards compatibility
for Boost users.

> Would not it be long-term proper to align boost::optional with
> std::optional? If that requires renaming boost in-place factories, then
> that might be a better long-term solution.

I read your suggestion as "rename current in-place factories form
boost::in_place to something else". Is that right?

> If, say, that additional functionality is later scheduled for std
> inclusion.

I am not sure what you mean here. I am pretty sure the in-place factories
will never be standardized, as we have a superior solution in C++11: tags
and perfect-forwarding of functions.


Boost list run by bdawes at, gregod at, cpdaniel at, john at