On Wed, Nov 26, 2014 at 10:54 AM, Felix Uhl
I was irritated by it at first, too, and if you think about it the comparison brakes
down to a philosophical problem:
If I have a pair of pants and you don’t, are my pants smaller than yours?
Hard to say, but to me the most logical solution is “no”.
My pants aren’t smaller than yours, and my pants aren’t larger than yours.
Also, your and my logic would apply to both the operator<(optional<T>, T)
and operator<(optional<T>, optional<T>), but I think we’re only talking about
the latter.
I had the same philosophical concerns. My initial reaction was that optional shouldn't have op<, because you don't know whether I want "none" to be the bottom or the top, or whether it makes sense for my T or my use case at all. A practical example is a list of cars for sale, ordered by price - do you want to see cars with no price listed first or last? Should optional decide that? Obviously optional<T> _can_ be ordered if T is ordered, which is why specializing "std::order" - which is currently spelled "std::less" - makes sense, and is worthwhile for containers. But my initial reaction was to not like op<. Furthermore, I originally only accepted op< for the sake of containers, before realizing std::less was probably the better way to go. tl;dr: I'd support dropping op< and only having ==, !=, and std::order/std::less. Tony