May I suggest that the type_traits identifiers all be placed in a boost::type_traits namespace, with one indirect #include file to grandfather existing usage? The added file, say hide_type_traits.hpp, would include all the detail .hpp files the way that type_traits.hpp does now. The individual detail files would wrap each API declaration in "namespace type_traits{...}". The present type_traits.hpp would simply: #include "hide_type_traits.hpp" namespace boost { using namespace type_traits; } The effect is that current usage will still work if you include type_traits.hpp as at present, but those of us who want the type_traits names (bit not the rest of boost) in the file namespace can do a "using boost::type_traits;" to achieve that. What prompts this note is a desire to prepare for TR1 while continuing to support old compilers. We attempted to say (in a file included when using an older compiler): namespace std { #include "boost/type_traits.hpp" } so that the boost type_traits identifiers would appear in the std namespace under an old compiler just as they would in a compiler that implements TR1. However, this blows up because the boost type_traits library transitively includes other boost stuff it uses, and that stuff does *not* like to be in std :-) Of course, we could leave all the identifiers in the boost space and pick them out one by one with using statements; that's in fact what we are doing. But that means we have to track your library with our using's, a maintenance nuisance. Lastly, may I suggest that future libraries with lots of identifiers should routinely use a per-module namespace, like the mpl library does now? That would obviate this nuisance should the library later be standardized. Ivan