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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2014-12-01 14:44:31

On Mon, Dec 1, 2014 at 10:58 AM, Olaf van der Spek <ml_at_[hidden]> wrote:
>
> IMO integers have a natural ordering, optionals don't.
>
Yes, you've said that.

> The ones that we've been talking about for the entire thread in almost
> > every reply. I'm not going to repeat again.
>
> vector? Doesn't use std:less for operator< does it?
> map/set?
>

Not vector. I was referring to set and map, whose use frequently doesn't
depend on what the ordering actually is, but often only that there simply
is an ordering. While on the topic though, the standard containers such as
std::vector /do/ use std::less for their operator< (even though the
requirements of the operation are [inconsistently] specified on the value
type's operator< rather than their default ordering function). This was
what I was alluding to when I said that the standard messes up requirement
specification for its comparisons. To twist the knife in the standard
committee's chest a bit, these types of requirement specification issues
would not exist at all had we had not abandoned C++0x-style concepts
(analogues of which are proving to work pretty well in Swift...). Checking
of constrained templates via archetypes would catch this particular class
of incorrectly constrained templates at compile-time, which is a feature
that concepts-lite advocates decry as unimportant. The fact that the
standard itself messes up requirement specification in this manner, despite
the scrutiny it undergoes, should be reason enough to reconsider...

Lots of types survive just fine without (default) ordering.
>

Simply surviving isn't all that one should strive for with respect to
general, composite types that are defined in boost or the standard library.

I think I'm still thinking about operator<
> Other then map, do you have a reference for all these algorithms etc
> that would benefit from less<optional<>>?
>

Any algorithm that takes a comparator and has a default (there are plenty
in the standard library). This is no different from the set and map cases
where you often don't care about the specific order, but rather, only that
an order exists. Depending on your specific use, this can be true with
respect to algorithms such as std::sort and std::binary_search, for example.

> lack of a default comparator for the types in question has already led to
> > the recommendation of preferring entirely different associative
> > datastructures over passing in an explicit comparator in this very thread
> > (ironically, the other containers that were recommended also depend on a
> > subjective default, only it's the default hashing function instead of the
> > default ordering function).
>
> How is the hash function subjective w.r.t. semantics?

Not all hash functions are created equal and there are reasons to
explicitly specify one as opposed to using the default, just as there are
reasons to explicitly specify an ordering function.

> > You should not be afraid to have your types be ordered when they can be
> > ordered. Most decisions in development have a subjective aspect to them
> and
> > precisely which default ordering comparator you provide is just one of
> > those many decisions. The fact that a default is subjective (and it
> always
> > is, even for arithmetic types), does not mean that a default is not
> useful.
> > Why do we use less as a default for arithmetic types with respect to a
> set?
> > Wouldn't greater be just as sensible?
>
> No, IMO, though for a lot of uses it probably wouldn't matter.
>

Why no? Why is "less" as a default objectively better than "greater" as a
default? It's simply not, we just use it by convention. The same is true
for why we frequently define other operators in terms of operator<. We
could just as easily have decided that operator> was the "base" operation
to be used as a default and around which we built other operators. < is
nothing special and not intrinsically better. I understand that you
personally intuitively like < best, but you're only kidding yourself if you
think that there is something deeper.

-- 
-Matt Calabrese