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

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-09-01 07:04:58

"Peter Dimov" <pdimov_at_[hidden]> writes:
> 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.

I just started reading this thread, half way through, and so I didn't know
what Doug's proposed ordering was until I looked it up. It turns out that his
ordering is exactly what I assumed it would be --- if the types are different,
then the one which comes first in the list is "less" than the other; if the
types are the same, compare the values. It seems natural to me.

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

Indeed, if people need different semantics, they are free to provide a
function; they can even supply it to standard algorithms and containers if
they wish.

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

I agree with Peter.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.