Re: [boost] Re: Re: [boost.variant] It is possible to make a variantLessThanComparable

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-09-01 04:54:35

Eric Friedman wrote:
> Peter Dimov wrote:
>> When there is one and only one strict weak ordering (equality) for a
>> type, not using operator< and operator== because some users might
>> have different expectations is misguided. It is pretty clear what
>> set<variant> or find(first, last, v) is supposed to do; variant_less or
>> variant_equal is "required boilerplate" as Howard says. :-)
>
> I'm not sure I agree. If the ordering scheme proposed by Dirk were
> 'natural' in some way (as in the case of arithmetic types,
> std::string, etc.) then I would offer no objection. But in fact it's
> quite arbitrary.

It's not arbitrary at all. Ask several randomly selected programmers what
operator< should do. It is not reasonable to declare the ordering
"unnatural" just because you don't like it. If there is one ordering, then
this is the natural ordering, whether we like it or not.

> While it is true that there is "one and only one strict weak
> ordering" for variant, it is not true IMO that there is one and only
> reasonable less-than comparison operation for variant. For instance,
> in certain contexts, it may make sense to allow comparison only
> between same types, returning false otherwise. In other contexts, it
> may make sense to allow comparison between any pair of bounded types
> of the variant (instead of simply between same types). Still in other
> cases, it may be desirable to allow comparison
> between a variant and non-variant type.
>
> My point is that different users may reasonably desire differing
> semantics. Worse still, I imagine many users will not realize their
> desired semantics are not universally desired, and so they may never
> think to read the docs for operator<(variant,variant).

Note heavy speculation. May make sense in certain contexts. May make sense
in other contexts. May be desirable. Users may reasonably desire different
semantics. Have you considered the possibility that, in practice, it/they
perhaps might not?

> The absence of such an operator forces the user to read the docs.
> That's my argument for boost::variant_before. It requires the user to
> demonstrate his/her intent explicitly.
>
> Other than the additional typing (the "required boilerplate"), are
> there other more fundamental objections?

The fundamental objection is that you should not penalize the majority
because someone "might need" different operator< semantics. Provide
operator<. Wait six months. Collect feedback. If there is evidence that
operator< is evil, remove it and document why it is not supplied.