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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2014-11-26 17:03:44

On Wed, Nov 26, 2014 at 10:54 AM, Felix Uhl <felix.uhl_at_[hidden]> wrote:
>
> 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