Re: [boost] [optional] Why was optional<T>::reset() deprecated?

Subject: Re: [boost] [optional] Why was optional<T>::reset() deprecated?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2016-03-02 09:17:05

2016-03-02 12:30 GMT+01:00 Andrzej Krzemienski <akrzemi1_at_[hidden]>:

>
>
> 2016-03-02 12:21 GMT+01:00 Beman Dawes <bdawes_at_[hidden]>:
>
>> On Wed, Mar 2, 2016 at 3:20 AM, Andrey Semashev <
>> andrey.semashev_at_[hidden]>
>> wrote:
>>
>> > On 2016-03-02 01:51, Andrzej Krzemienski wrote:
>> >
>> >> At some earlier stages of development, boost::optional did not have the
>> >> assignment from boost::none_t (and probably also from T); and reset was
>> >> the
>> >> only way to efficiently change the optional from the state of having
>> the
>> >> value to the state of not having the value.
>> >>
>> >> After the addition of more fancy syntax (conversion to bool, assignment
>> >> from none_t), reset() (and is_initialized()) became redundant, and
>> hence
>> >> the deprecation.
>> >>
>> >> I got that from reading Boost mailing archives once.
>> >>
>> >
>> > FWIW, I don't think that having support for 'none' is enough reason to
>> > deprecate 'reset' (same for 'is_initialized'). I know some of my
>> colleagues
>> > who prefer these methods to the fancy syntax because it feels more
>> aligned
>> > with other Boost and standard library components. Having 'reset' also
>> > allows not to include boost/none.hpp.
>> >
>>
>> The standards committee's library enhancements working group (LEWG) agrees
>> with you. Nevin's question came up in the context of aligning several
>> Library Fundamentals TS functions with each other and the rest of the
>> standard library. The proposal is progressing and will likely be part of
>> C++17.
>
>
> P0032
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0032r1.pdf>
> mentions reset() with no arguments. I can un-deprecate this overload when
> the proposal is accepted. I am not sure about the overload with T: we have
> a more generalized emplace() for this purpose.
>
> Regards,
> &rzej
>

Regarding the broader problem of compatibility between boost::optional and
std::optional, I see a bigger issue. Name in_place is already reserved in
namespace boost for In-place Factories
<http://www.boost.org/doc/libs/1_60_0/libs/optional/doc/html/boost_optional/in_place_factories.html>.
I am not sure how to approach it.

Regards,
&rzej