"Peter Dimov" <[EMAIL PROTECTED]> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
