On Thu, Nov 20, 2014 at 8:13 AM, Bjorn Reese
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