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

Subject: Re: [boost] Pervasive dependency upon mpl::bool_
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-02 18:04:22

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