On Wed, Nov 2, 2011 at 6:20 AM, Andrew Sutton <asutton.list@gmail.com> wrote:
17.6.3.1? It's in 20.1.1 [lib.equalitycomparable] in C++03 and in 20.2.1 [utility.arg.requirements] in N3225. In C++03, the preceding text states:
In Table 28, T is a type to be supplied by a C + + program instantiating a template, a, b and c are values of type T.
Hmm.. the n3290 seems to place them in 17. I see the wording that establishes the types now.
It makes sense, too; the table describes what it means for T to be EqualityComparable. What would be EqualityComparable if a, b and c were arbitrary?
It should not be defined for arbitrary types. I've never argued that it should -- quite the opposite, in fact. What I've said is that the definition generalizes to a well defined subset of types.
I don't understand at all the benefits of defining EqualityComparable formally in this case. What's wrong with providing an "as if" specification of the algorithm, that is, show one example of its implementation and require that alternative implementations are equivalent? As long as that works with a separately defined EqualityComparable entities, there is no need to couple the algorithm with that definition. Practically speaking, the possibility of abuse the other approach attempts to protect against isn't a big deal, as long as people know what works and what doesn't. What C++ feature isn't prone to abuse anyway? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode