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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-11-27 08:22:43

2014-11-26 17:49 GMT-06:00 Gavin Lambert <gavinl_at_[hidden]>:

> 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.
>

I tend to agree with this reasoning op< and std::less should go in pair. In
this sense I consider the case of pointers a bug.

I would even go as far as to risk the following hypothesis. operator< in
C++ is something different and more than comparing magnitudes in the
mathematical sense: it should represent a default total order (not
necessarily the natural total order". In the spirit of this reasoning, I
would dare to claim that op< could be added to complex<double> with the
semantics of lexicographical order.

>
> 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.
>

http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/quick_start/storage_in_containers.html

>
> 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.
>

Agreed. Technically, the behavior of  op<(optional<T>,T) is well-defined
and consistent with the conceptual model of optional. However, every
practical use case I have seen so far is a programmer bug.