Ivan Godard writes:

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.

FWIW, if your goal is to prepare your codebase for TR1, you probably _do_ want to control which parts of Boost.Type Traits go into 'std'/'tr1' on case-by-case basis. -- Aleksey Gurtovoy MetaCommunications Engineering