Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2014-11-20 13:36:51

On Thu, Nov 20, 2014 at 8:13 AM, Bjorn Reese <breese_at_[hidden]>
wrote:

> On 11/20/2014 11:49 AM, Andrzej Krzemienski wrote:
>
>  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.
>>
>
> As optional is a nullable type, it could be useful to let the comparison
> operators return a tri-bool instead of a bool.

I don't think I agree. none doesn't mean "indeterminate." If two things are
none then they are equal, much like how two null pointers are equal. If we
have a desire for a generalization of tribool, I.E. "indeterminable<T>" or
something along those lines, then it should really be its own type.

In practice, though, I find such types really difficult to work with as
they are irregular and I'm not convinced such types are worth existing
(admittedly I think I might be in the minority here). Having comparison
operators return something other than bool, especially something like
tribool, or if those operators simply behave as tribool comparisons do,
makes it difficult to use such types in generic code and can cause things
to break in weird ways without a compile error. This is because == in such
a case is not actually an equivalence relation and the relational operators
are not a partial order, which goes against assumptions in [some] generic
code, not to mention against most people's intuitions when they see such
operators in use. Perhaps it's an assumption that people shouldn't make,
but at the same time, I see no tangible benefit to having the operators
behave that way over just having a separate named function, if that. I've
never really been convinced that floating point (with respect to NaN) and
tribool behavior regarding comparisons is a good idea, but again, I think
I'm in the minority there.

As a side note, the old concepts proposal even made this assumption. When
operator == is defined for a type and it returns something convertible to
bool, it is assumed to be a model of an equivalence relation (rather than
requiring someone to explicitly state that they model the concept). This is
also the general assumption that most people make as well, so I don't think
we should break that assumption.

-- 
-Matt Calabrese