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

On Thu, Nov 27, 2014 at 8:08 PM, Vicente J. Botet Escriba 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 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 using std::less<T>.

Yes. We currently have that much - std::less 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