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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-11-26 18:49:26

On 27/11/2014 11:03, Gottlob Frege wrote:
> tl;dr:
> I'd support dropping op< and only having ==, !=, and std::order/std::less.

TBH, other than the "existing code" issue I'm not sure I like the idea 
of std::less working but op< not -- and in particular if you don't agree 
with the idea that "none is less than any other value" then I don't know 
why you'd agree with the idea that it should sort that way in a map, 
which is what you appear to be suggesting.

Perhaps std::less should not support it either, but std::hash should, 
and if you want to use optional keys then you have to use 
std::unordered_map instead?

But why do you want to have optional keys anyway?  When does it make 
sense to have a single value attached to an empty key?  It's rare for a 
dictionary type to permit null keys in any language.

OTOH, I don't have any personal problems with 
op<(optional<T>,optional<T>) existing and with its current behaviour, 
other than the apparent disagreement about where "none" should sort (and 
I don't have any issues with the library author having defined this as 
"less", though apparently others do).

I'm less convinced of the merit of op<(optional<T>,T), as the reality is 
that in *real life code* this is most likely to be a coding error rather 
than something intentional.  Perhaps this is just a failure of 
imagination, but other than toy examples I cannot imagine a case where 
someone would use this intentionally.  I'm not sure I'd go as far as 
advocating that they be explicitly removed or poisoned, but I suspect 
that this would improve overall code quality without unduly burdening 
people who do want to make this comparison.

I am absolutely convinced of the merit of implicit optional<T>(T) 
construction and assignment, and op== working for both, and would regard 
it as a bug if these were removed.