On Thursday, November 20, 2014 4:04:25 PM UTC+1, dar...@gmail.com wrote:
On Thursday, November 20, 2014 11:49:42 AM UTC+1, Andrzej Krzemienski wrote:
Perhaps other use cases of operator< could be presented.
I was trying to illustrate how it is useful to think of optional<T> as extending the domain of T (rather than representing "either T or
error").
Not to illustrate the storage in containers.
The user-provided int can be any value of int plus the situation where user decides not to type any input. the latter is a valid and useful information. E.g. when an int represents some threshold, having boost::none means "go with no threshold". boost::none is just a value. this in turn implies the implicit conversions:
optional<int>() != 2;
The above is logical and useful, even outside of the containers.
my 2 cents (as a user of boost::optional):
Is optional<int>() < 2 true or false? And 2 < optional<int>()?
To me the problem is how the extended domain is sorted, i.e. how optional<T>() is sorted vs all the possible values of T. If the ordering is not clear, then no comparison operators should be provided.
That said, equality (and inequality) are meaningful and should be provided.
Regards
Andrzej has kindly pointed me to the most up-to-date docs, where this is clarified in two places: http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/q... http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/t... I think a link from the reference to the clarification would be very useful. Now I agree it is clear how optional<T>() is sorted wrt to T and it is up to the user to know the tool. FWIW, now I don't see the need for safe_optional.