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-30 18:20:03

On 29/11/2014 08:01, Gottlob Frege wrote:
> There are still reasons to use std::map over unordered_map.  Lack of a
> cryptographically safe hash is one of them.  There are others (that
> I've forgotten, but I've asked the same question to committee members
> before, and there were a few reasons that sounded valid to me.)

Why should the lack of a cryptographically safe hash matter when you are 
not doing cryptography?

It doesn't really matter what hash is used in internal data structures. 
  (Although obviously there are desirable properties such as having 
uniform spread to minimise bucket collisions and improve lookup speed.)

In fact in most cases the best hash is the fastest one, not the most 
secure one.

> Basically, people still want complex (for example) as a key in
> std::map. Maybe that is becoming rare enough that they can just pass
> in an explicit comparison when needed, but not always easy in generic
> code (more on that below).

I still question whether these people *really* want this, or whether 
it's just because unordered_map is new and scary (or longer to type). 
Obviously I suspect the latter.

>>> optional<T> is Regular if T if Regular.  The more that optional<T>
>>> "just works" like int works, the better.   Particularly for generic
>>> code.
>>
>> The first part sounds like a definition I am unfamiliar with.
>
> Regular is a concept. See Stepanov's Elements of Programming.  Or just
> think "int".  ie assignable, copyable, copies are disjoint, etc.
> Stepanov includes ordering as part of Regular (IIRC).

Thank you for the clarification.  I agree that this is a desirable 
property for "value-like" types, which includes optionals and variants. 
  I don't agree that ordering should be included in that set, however 
(but equality should).

Structures, for example, should ideally be 
assignable/copyable/equality-testable etc and be treated value-like in 
the same way.  But most of the time defining an ordering for a structure 
is meaningless.

The same is true for variant; I don't think it makes sense to compare a 
variant that holds type #4 with one that holds type #7 and somehow 
declare that the first is less based just on the types.

Optional is more borderline.  I don't really have a problem with 
comparing two optionals, or even the default "none is less than 
anything" relation.  But when you start mixing comparisons with 
implicitly-promoted-non-optionals you increase the risk of unintended 
bugs (eg. opt < 5 is true but the intended comparison was opt && *opt < 
5, which is false).