John Maddock wrote:
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?