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-28 14:22:23

On Thu, Nov 27, 2014 at 8:08 PM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
>>>
>>> 0 - std::less should be same as op<
>>> (I think we all agree here, actually, which is why we should have
>>> std::order)
>
> Only if op< id defined.

Do you mean only *the same* if op< is defined, or only *exists* if op<
is defined?
If op< isn't defined (ie complex<> or, technically, pointers) do you
still want std::less?

>>>
>>>
>>> 1 - op<(optional<T>, optional<T>) is "sensible" but somewhat arbitrary
>
> I don't agree here. We don't need anything arbitrary.
> op<optional<T>,optional<T>) must be defined only if op<(T,T> is defined.

It is arbitrary in the sense of where "none" is ordered.

I (strongly!) agree with the only if op<(T,T> is defined.
(And famously believe op>=(optional<T>,optional<T>) should be based on
op>=(T,T), instead of !op<(T,T) )

>>>
>>> 2 - op<(optional<T>, T) is questionable, often (usually?) wrong
>
> Agreed.
>>>
>>> 3 - in general, func(optional<T>, optional<T>) should work if passed
>>> T's (ie implicit conversion is important)
>
> I have my doubts here. Implicit conversions provide often (usually?)
> unexpected behavior.

I think we need a general guideline for the std library for when
implicit is OK.  ie Is it OK for dumb_ptr? string_view? etc.
That's something I'd like to work on.  I _think_ there is a general
guideline, but maybe it is too case-by-case?

>>>
>>> 4 - op<(optional<T>, optional<T>) *is* of the form func(optional<T>,
>>> optional<T>) - ie why should it be different?
>
> Nothing to say here ;-)
>>
>>
>>
> Currently we have std::less, not std::order and the STL ordered containers
> are using as default comparator std::less. So let define
> std::less<optional<T>> using std::less<T>.
>

Yes.  We currently have that much - std::less<optional<T>> is built
with std::less<T>, not op<(T,T).
Even if only for the sake of pointers. On almost-non-existent
hardware, (and maybe future hardware).

Tony