Re: rel_ops issues

[Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>]

Joe Buck <jbuck@racerx.synopsys.com> writes:

[...]

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

The point is that we recommend user not to bring std::rel_ops contents
in scope.  That is that simple.  The library can't fix users' broken
code. 

[...]

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

Before questioning my understanding of function templates and how to
use them in real world libraries, you might to learn more about them,
what is there and what isn't there.

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

Library designers have known for a long time that std::rel_ops should
not be considered.

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

And you might also want to carefully consider what he wrote.

As an aside, what is good to write to explain a specific topic in a
book isn't necessary good to copy religiously in a real world library.

And finally, the problem isn't really that of function overloading,
the problem stems from how name lookup works.

Again, __normal_iterator needs tobe corrected, but solutions
mentioning std::rel_ops are just that: wrong.  

[...]

| 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++)

I prefer the latter.

-- Gaby