Le 02/03/2016 12:30, Andrzej Krzemienski a écrit :
2016-03-02 12:21 GMT+01:00 Beman Dawes <bdawes@acm.org>:
On Wed, Mar 2, 2016 at 3:20 AM, Andrey Semashev <andrey.semashev@gmail.com 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>