2016-03-02 9:20 GMT+01:00 Andrey Semashev :

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.

Agreed. This is why I have no intention of removing them. But there is also a downside to keeping two ways to do the same thing: developers often do not understand one another's code. I left the deprecation to encourage a move towards one interface.

Having 'reset' also allows not to include boost/none.hpp.

You cannot avoid including boost/none.hpp. Whenever you include boost/optional/optional.hpp, boost/none.hpp is indirectly included. Regards, &rzej

2016-03-02 10:22 GMT+01:00 Andrey Semashev :

On 2016-03-02 11:39, Andrzej Krzemienski wrote:

...

2016-03-02 9:20 GMT+01:00 Andrey Semashev :

Having 'reset' also allows not to include boost/none.hpp.

...

You cannot avoid including boost/none.hpp. Whenever you include boost/optional/optional.hpp, boost/none.hpp is indirectly included.

Well, at least in the user's code I can avoid it (less typing). But isn't none_t.hpp enough for optional's needs?

Technically, it should be possible to get away with it and create my own constants of type boost::none_t (I think I sometimes need them in expressions). But the total gain would be negligible. Regards, &rzej

On 2016-03-02 14:21, Beman Dawes wrote:

On Wed, Mar 2, 2016 at 3:20 AM, Andrey Semashev 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.

I'm glad to hear it!

2016-03-02 12:30 GMT+01:00 Andrzej Krzemienski :

2016-03-02 12:21 GMT+01:00 Beman Dawes :

...

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.

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/i.... I am not sure how to approach it. Regards, &rzej

2016-03-03 13:23 GMT+01:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr>:

Le 02/03/2016 12:30, Andrzej Krzemienski a écrit :

...

2016-03-02 12:21 GMT+01:00 Beman Dawes :

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 was incorrect. opt_v.reset(v); is in fact equivalent to: opt_v = v; I guess that the two reset's were deprecated in favor of two assignments: opt_v.reset(); opt_v.reset(v); is equivalent to: opt_v = none; opt_v = v; Regards, &rzej

2016-03-04 3:14 GMT+01:00 Gavin Lambert :

On 2/03/2016 11: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.

It still bothers me a bit that none and nullptr are separate. Do we really need two different ways to spell "nothing"?

I suppose there is a use case for optional<some-pointer-type> which could have distinct states for "no pointer" vs. "null pointer" vs. "valid pointer", but how often do you really need to distinguish the first two states?

(Although I guess if you didn't want to distinguish them, you'd just use some-pointer-type directly instead of wrapping it in an optional. So I understand the presumed rationale, it just seems weird.)

See here for an extended rationale for not using nullptr in std::optional: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#rationale... This rationale apart, I would argue that nullptr does not say "nothing" but "no pointer (of any type)". But then, you are probably right that this dilemma is not really faced by the programmers very often. Regards, &rzej

Gavin Lambert wrote

It still bothers me a bit that none and nullptr are separate. Do we really need two different ways to spell "nothing"?

I suppose there is a use case for optional <some-pointer-type> which could have distinct states for "no pointer" vs. "null pointer" vs. "valid pointer", but how often do you really need to distinguish the first two states?

I have one such case in one project with optional where I have to distinguish nullptr from none, meaning "don't know". And I have several cases where nullptr means "override some pointer with nullptr" and none means "don't override that pointer." -- View this message in context: http://boost.2283326.n4.nabble.com/optional-Why-was-optional-T-reset-depreca... Sent from the Boost - Dev mailing list archive at Nabble.com.