Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?

Vincente J. Botet Escriba wrote:
I hope it is clear now that I don't want to change optional but see what the safer optional could be with the ongoing C++ proposals.
Fair enough, different users want different behaviour, but how is optional not safe in any way? operator<(optional<T>, T) does not throwing any kinds of exceptions when operator<(T,T) doesn’t, does it? --- Felix Uhl

Le 26/11/14 09:24, Felix Uhl a écrit :
Vincente J. Botet Escriba wrote:
I hope it is clear now that I don't want to change optional but see what the safer optional could be with the ongoing C++ proposals.
Fair enough, different users want different behaviour,
but how is optional not safe in any way?
Sorry, this should go to the Andzej's post on safe optional. optional<T> is not less safe than T*. Any access using pointer like operators need to ensure that the pre-condition is satified. I have no problem with this probably valued types with unsafe interfaces. In some application I could be interested in using some safe_optional<T> or safe_ptr<T> that don't allows to get the optional value or the pointed value, but just allow to visit the value when available, even if this interface implies a less efficient implementation as a check would be done on any access. As you can see this safe issue is not specific to optional<T>, but to any type that can probably store a value. Other types in this category are smart pointers, expected, future, any, variant. Vicente
participants (2)
-
Felix Uhl
-
Vicente J. Botet Escriba