Re: rel_ops issues

[Joe Buck <jbuck at racerx dot synopsys dot com>]

> Hmm I'm unclear of why you think it *must* be made to play nice.
> This has been debated to death by the committee, and the consensus was
> to isolate them in  a separate namespace -- that was the polite way to
> say they weren't brilant ideas to start with.  If an user wants to
> break his own code with those operators, he is free to say whatever
> incantation which has the desirable effect.  V3 has no business to
> bring them into std.

You misunderstand.  I am not asking you to bring them into std.  They
belong in std::rel_ops.  That is what the standard says.

However, if the user brings them into the global namespace with a
using directive, it is not permissible for the STL to completely break.

> No, Nathan's comment was not wrong -- I tend to think it should be
> more definitive.

Nathan's coment was only partially wrong.  He was right to say that the
rel_ops are too greedy and should be isolated.  He was wrong to use
this as a justification to leave things broken.

> | using std::rel_ops::operator!=;
> | 
> | and also use STL classes must work. 
> 
> Programs which say that incantation deliberately choose to break --
> the library has no business to fix that.  Sorry.

Clearly you don't have an adequate understanding of partial
specialization.  (Please be clear: I'm confident that you understand
it as a compiler developer.  But you lack understanding of how to use
it as a library designer, or you would have fixed this problem in five
minutes).

With a proper library, the only programs that can ever be broken by
importing std::rel_ops are programs where some class defines operators
!=, ==, >=, or <= to not have the mathematical relationship with
== and < defined by the rel_ops operators, or where they return non-bool.

If you are convinced that the compiler is allowed to barf on programs that
import rel_ops, please write to Bjarne and tell him to change many of the
examples in his book.

> __normal_iterator needs to be fixed.  Right.  But std::rel_ops isn't
> the cure.

See my other message for the cure.  I'd just send you a complete patch
if it weren't for issues I'm having with a company lawyer who objects
to the FSF assignment patent language.

Also note that you can say

	using std::rel_ops::operator!=;

just within one function.  If you refuse to do that in cases like
std::equal, then your only other choice is to replace the != by
something like
	!(*a++ == *b++)
because otherwise you are imposing a requirement that is not in the
spec (that there be an operator!= defined, where the spec only
requires operator==).