Re: [boost] Pervasive dependency upon mpl::bool_

Le 02/06/14 17:39, Peter Dimov a écrit :

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 not documented, so the user or the boost library is using an undocumented feature and must be changed.

This is existing code, both inside and outside Boost. I hope that we don't mind breaking code that is using undocumented features.

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).

+1 for using the existing std when available.

This still breaks the above use case, as boost::is_something will derive from boost::true_type, but not from mpl::true_.

No from my perspective.

We could add converting constructors to mpl::bool_ taking core::bool_, which will fix the above, but may break other, more convoluted uses. Hugh

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 {};

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.

IIUC you are proposing to split the type_traits into two levels, those that don't depend on MPL and those that depend on MPL. I would like to break the dependency from type_traits and MPL if possible. And you proposal seems a good transition, but a little bit artificial. Putting MPL and Type Traits on the same module would reduce the dependencies also.

That's a real project though. Not just moving a few headers around. :-) Agreed.

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.

Yes the best it to see case by case. Could you show a concerte/real example so that we are fixed on the proposed approach. Vicente