We have lots of headers that depend on mpl::bool_ in order to define traits classes as deriving from mpl::true_ or mpl::false_. I don't think that this dependency is necessary even for MPL interoperability. The normal way of template<class T> struct trait { BOOST_STATIC_CONSTANT( bool, value = false ); }; should work just as well. I think. As one example, there's detail/blank.hpp, which starts with #include "boost/mpl/bool.hpp" #include "boost/type_traits/is_empty.hpp" #include "boost/type_traits/is_pod.hpp" #include "boost/type_traits/is_stateless.hpp" It doesn't really need these includes. namespace boost { struct blank { }; // type traits specializations // template <> struct is_pod< blank > : mpl::true_ { }; This can be written as template<class T> struct is_pod; template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); }; which requires no includes. The problem is, though, that all type traits do derive from mpl::true_ or mpl::false_, and I'm not sure if rewriting blank.hpp in the above manner is actually correct. Should type trait specializations always derive from mpl::true_ or mpl::false_? Will I break something if I specialize a type trait to not derive from mpl::bool_? Or is a nested ::value enough? Who knows. :-) But really, if a header, whose entire purpose is to define an empty struct, can't get by without including type traits and mpl, we've lost the dependency game before it's even started.