[optional] Why was optional<T>::reset() deprecated?
Does anyone know? We are considering adding it to std::optional this week. Thanks, -- Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>> +1-847-691-1404
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. Regards, &rzej 2016-03-01 22:58 GMT+01:00 Nevin Liber <nevin@cplusplusguy.com>:
Does anyone know? We are considering adding it to std::optional this week.
Thanks, -- Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com
+1-847-691-1404
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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.
2016-03-01 22:58 GMT+01:00 Nevin Liber <nevin@cplusplusguy.com>:
Does anyone know? We are considering adding it to std::optional this week.
Thanks, -- Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com
+1-847-691-1404
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2016-03-02 9:20 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
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
On 2016-03-02 11:39, Andrzej Krzemienski wrote:
2016-03-02 9:20 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
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?
2016-03-02 10:22 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
On 2016-03-02 11:39, Andrzej Krzemienski wrote:
2016-03-02 9:20 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
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 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. --Beman
On 2016-03-02 14:21, Beman Dawes wrote:
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.
I'm glad to hear it!
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. Regards, &rzej
2016-03-02 12:30 GMT+01:00 Andrzej Krzemienski <akrzemi1@gmail.com>:
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.
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
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>
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 <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 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
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.)
2016-03-04 3:14 GMT+01:00 Gavin Lambert <gavinl@compacsort.com>:
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
Le 04/03/2016 03:14, Gavin Lambert a écrit :
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"?
[2] pretends to have a single name for all. But need some customization :(
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.)
I agree those cases are not very common, but it is not easy to argument that they can be ignored. Vicente [2] <https://github.com/viboes/std-make/blob/master/doc/proposal/factories/DXXXX_factories.md>
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<shared_ptr> 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.
participants (7)
-
Andrey Semashev -
Andrzej Krzemienski -
Beman Dawes -
Gavin Lambert -
Marcel Raad -
Nevin Liber -
Vicente J. Botet Escriba