These two problems could be avoided if we were to have core type traits > whose interface consisted solely of a member integral constant called > "value", without any other required members or base classes, and which > were only allowed to depend on Config or StaticAssert.
I'm less keen on this because it fractures the lib into two conceptually different parts. Let me mess around with some code and see if something better is possible.
As I tried to explain further down, it simply separates the two already existing layers in the library: the part that computes the value of the trait, which results in something like is_pointer_impl<T>::value, and the part that defines the trait, which is generally implemented like this:
BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_pointer,T,::boost::detail::is_pointer_impl<T>::value)
This separation is natural, in that the library already does it.
You're right that some traits will not be able to fit into the core part, most obviously common_type. But the users of the core part generally do not need them; and for those who do, well, they'll have to bite the bullet and use TypeTraits.
Or perhaps I'm missing your point?
I think so - the inner detail layer is exactly that - an implementation detail. It's also a horrible mess that got added when I wasn't looking when mpl was added to Boost - that was sort of OK then as it seemed to be the only way to make things work, but that's no longer true and there's an opportunity here to remove all that obfuscation and crud and produce something that's actually halfway readable and maintainable. But my broader point was that this generates two separate traits called is_pod (for example), with slightly different interfaces and conceptual requirements on usage. IMO this is a "really bad thing" and we can do much better. John.