Re: Another Koenig lookup thread, yes, kill me now

Now, I don't want to start a flame thread, and I apologize for
bringing this up. However, I do have a couple things I would like
clarified. To start, here's one of the well known problems with
Koenig lookup.

// **** main problem
namespace A
{ class foo {};
    template <typename T> void helper (T) {}
}

namespace B
{ template <typename T> void helper(T ) {}

    template <typename T>
    class set
    {
    public:
        set()
        { T tmp;
            helper(tmp);
        }
    };
}
int main() { B::set<A::foo *> s; }
// ****

I actually had this happen to me in production code. I ended up
changing
    int main() { B::set<A::foo *> s; }
to
    int main() { B::set<void *> s; }
to get around Koenig lookup, and static_cast'ing on each use. I
really disliked how I had to abandon type safety. I was in a no win
situation. namespace B was the compiler's STL, and namespace A was a
company-wide header which was not going to change.

I post this to make sure I understand all of the problems Koenig
lookup is supposed to solve. Here are the two big examples of which
I know.

// **** ex 1
#include <iostream>
int main() { std::cout << "foo\n"; }
// **** ex 2
namespace A { class foo {}; void bar(foo ) {} }
int main() { A::foo x; bar(x); }
// ****

Solution #1 - As it stands now without Koenig lookup.
Without Koenig lookup, the first problem of finding the function
operator << can be solved with the ever dreaded "using namespace
std;" or a more limited "using std::operator <<;". The second
example can be made to compile without Koenig lookup with "using
namespace A;", "using A::bar;", or explicitly specifying which bar
"int main() { A::foo x; A::bar(x); }".

Solution #2
One alternative already proposed in a thread on this newsgroup is to
make each operator function into a member function or into a global
scope global function. (I don't know how lookup would work without
Koenig lookup for infix operator notation, so if necessary change
the lookup rules to consider a member function of the left operand
when using infix operator notation.) This is polluting the global
namespace, but not in a meaningful way. Moving these operators to
global scope does not change the space of functions which the user
can declare and use. With Koenig lookup and the original function in
namespace scope, defining and using another produces an ambiguous
call error. With the original function at global scope, a second
ser- defined function will run afoul of the One Definition Rule.
(Arguably though, solution #2 can be a link time ODR violation,
which is not required to be diagnosed IIRC, whereas as it stands
now it's a compile time error.)