Vicente J. Botet Escriba wrote:
template <> struct is_pod< blank > : true_type {};
This still breaks dispatch on mpl::true_/mpl::false_. The use case is: void f( mpl::true_ ); void f( mpl::false_ ); struct X; int main() { f( boost::is_something<X>() ); } This is existing code, both inside and outside Boost. Rob Stewart wrote:
Put a few pieces into core and change MPL to use or derive from them. For example, mpl:: true_type can derive from a new boost::true_type (which could be an alias for std:: true_type).
This still breaks the above use case, as boost::is_something will derive from boost::true_type, but not from mpl::true_. We could add converting constructors to mpl::bool_ taking core::bool_, which will fix the above, but may break other, more convoluted uses. The 'proper' way to handle that (and the problem with type traits using MPL is not limited to mpl::bool_) is to extract the actual type traits into core type traits, which do not derive from anything, do not include MPL lambda support, and whose implementation does not include a non-core library (which is an issue only for type_with_alignment and common_type). Then, the current type traits would be rewritten as template<class T> struct is_something: integral_constant<bool, core_type_traits::is_something<T>::value> {}; and can still include the MPL scaffolding for people who like that sort of thing. blank.hpp will then specialize the core type trait and the ordinary type trait will still pick up the specialization. That's a real project though. Not just moving a few headers around. :-) But it's tractable. The good thing is that the core type traits do not have to be written all at once. We can migrate them one by one, at a leisurely pace.