The boost::swap utility forwards its task to a helper function, ::boost_swap_impl::swap_impl. I /think/ that this top-level namespace, "boost_swap_impl", is there only "for historical reasons", because it was part of an ADL barrier. This ADL barrier is now replaced by a superior technique to avoid ambiguity, giving boost::swap an extra template argument as suggested by Steven Watanabe: // From http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp namespace boost { template<class T1, class T2> void swap(T1& left, T2& right) { ::boost_swap_impl::swap_impl(left, right); } } So now I think it's preferable to remove the top-level namespace, "boost_swap_impl", and move the helper function into the boost namespace. For instance within a new nested namespace, boost::swap_impl_detail. Right? The name "boost::swap_impl_detail" should indicate to the user that she should not call swap_impl directly, because it's only an "implementation detail" of boost::swap. Or would it be preferable to have the swap_impl function "officially" accessible to the end user? If so, we might move swap_impl to the boost namespace, and rename it to something more "user friendly". (I would like to have it named, e.g., "boost::swap_using_adl".) I can think of two reasons why end-users might want to call swap_impl directly, instead of calling boost::swap: It /might/ in some cases, on /some/ platforms, perform /slightly/ better than boost::swap, because it would skip one function call. And secondly, swap_impl allows the user to specify the type of both function arguments by one single template argument. While the current boost::swap utility no longer does. For example: class animal_base_class {}; class cat_class : public animal_base_class {}; class dog_class : public animal_base_class {}; void swap(animal_base_class &, animal_base_class &) {} int main() { cat_class cat; dog_class dog; std::swap<animal_base_class>(cat, dog); // Okay. boost_swap_impl:: swap_impl<animal_base_class>(cat, dog); // Better: using ADL. boost::swap<animal_base_class>(cat, dog); // Compile error! } Of course we could also just keep the swap_impl function as an unsupported "implementation detail" for a while, until a user might want to use it... What do you think? -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center