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 setvariant
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.
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).
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? (variant in generic contexts, for
instance...?)
Thanks,
Eric
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
