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-02 16:46:55

On Tue, Dec 2, 2014 at 5:10 AM, Olaf van der Spek <ml_at_[hidden]> wrote:

> On Mon, Dec 1, 2014 at 8:44 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> > Not vector. I was referring to set and map, whose use frequently doesn't
>
> Just two? That's not what I'd call many datastructures.
>

Well, technically 4 (multi-versions), but keep in mind that that is 100% of
the ordered datastructures. This is also just in the standard. Other
library developers can and do use std::less appropriately.

> > 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
>
> I'm not sure what you're saying.
> Requirements specify operator< but they're using std::less? I'm confused.
>

Yes, that is what I'm saying. In the C++ standard, when library components
are specified, it describes concept requirements and contracts on types and
functions involved. Sometimes it goes further and specifies more specific
implementation details. In the case of the comparison operators, the
standard states that the requirements are that operator< of the value type
of the container must be defined and that it forms a total order. However,
when it specifies what the operators should do, that specification is in
terms of std::lexicographical_compare, using the default ordering
(std::less). These two specifications do not match as std::less and
operator< do not necessarily relate (they differ with respect to certain
fundamental types and library components, not to mention that they can
differ in user code). Either the requirements or the implementation are
incorrectly specified.

My jab regarding concepts was that the (good) C++0x concepts proposal could
have potentially caught this kind of mistake when a vendor implemented the
library because the definitions would have been constrained. However, this
type of checking is not a part of concepts-lite and its design essentially
precludes that checking from getting there in future revisions.
Concepts-lite deems that kind of checking "unimportant" even though the
standard could have benefited from the feature (not to mention other
library developers).

> > 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.
>
> True, but not an answer to the question.
>

I'm not sure what you mean with respect to semantics in this context.
Regarding ordering, the semantics that matter don't differ either.

> Why no? Why is "less" as a default objectively better than "greater" as a
> > default?
>
> Because in the majority of cases people order stuff in ascending order.
>

First, I'm not even sure that that's true and you certainly do not either
(beyond that, it could be entirely incidental). Even if that were true, it
also has no bearing on the discussion. It could be 99% of the time and that
would make no difference.

-- 
-Matt Calabrese