Boost logo

Boost :

Subject: Re: [boost] [optional] Why was optional<T>::reset() deprecated?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-03-03 07:23:51


Le 02/03/2016 12:30, Andrzej Krzemienski a écrit :
> 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.
>
>
Yes, reset() is not an assignment and std::optional::emplace do what
boost::optional::reset(T) does, isn't it?

I've proposed to have std::none for std::optional and std::any [1] but
it seems that LEWG is requesting to explore none<T>. I see how to do
none(), none<optional>(), none<optional<int>>(), none<any>() [3]
(no_value in [2]) to std::optional and std::any. However this is much
more complex that a simple none_t and needs some customization :(.

Vicente

[1] <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0196r0.pdf>
[2]
<https://github.com/viboes/std-make/blob/master/doc/proposal/factories/DXXXX_factories.md>
[3] <https://github.com/viboes/std-make>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk