Unless I'm just observing a bug in Comeau, I've just discovered something. In http://www.boost-consulting.com/writing/qn.html I note that, as a means of algorithm customization... library writers are unlikely to invite users to overload functions in the library's namespace, since: a. It is syntactically heavy and inconvenient for users to define overloads in other namespaces: // user.hpp namespace user { class my_class; } // * Extra commented lines required to // * produce overloads in lib:: and namespace lib // * return to user::. Moves f() away { // * from my_class. void f(user::my_class) // also explicit qualification of my_class } // * // * namespace user // * { // * b. Qualified lookups of names from function templates are subject to dangerous order dependencies, since qualified names bind at the point of definition. // lib.hpp namespace lib { template <class T> void f(T); template <class T> void g(T x) { lib::f(x); // binds only to visible fs } } // user.cpp #include "lib.hpp" #include "user.hpp" // defines f overload too late int main() { user::my_class x; lib::g(x); // calls lib::f(), not user::f()! } It seems that's true for qualified names, but when ADL is disabled with parentheses, names aren't bound until the point of instantiation: // lib.hpp namespace lib { template <class T> void f(T); template <class T> void g(T x) { (f)(x); // not bound here } } // user.cpp #include "lib.hpp" #include "user.hpp" // defines some user::f overload int main() { user::my_class x; lib::g(x); // calls user::f() } This hardly removes all the problems with namespaces and ADL, but maybe it restores "overloading in the library's namespace" to viability as a customization technique? -- Dave Abrahams Boost Consulting www.boost-consulting.com