Subject: Re: [boost] A proposal for the creation of a new module, Core Type Traits
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-08 14:29:05
Le 07/01/15 21:20, Peter Dimov a écrit :
> This is a more formal statement of the same suggestion I've already
> given in other threads.
> Currently, library developers who need type traits functionality face
> a choice: either to use the TypeTraits library, and make their
> libraries dependent on MPL, Preprocessor, TypeOf and Utility, or to
> duplicate its functionality locally.
> Similarly, developers who want to specialize a type trait on a type of
> theirs, even a trivial empty struct, need to include the TypeTraits
> headers for the traits to be specialized, which brings in MPL and
> Preprocessor on a header-level, and makes their module dependent on
> TypeTraits and its dependencies listed above.
> Local replication, as in Boost.Move, rightly attracts charges of code
> duplication, with the associated potential maintenance problems when
> the implementations diverge.
> 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.
> This solves the second problem because it will then be possible for a
> developer to specialize a trait, such as is_pod, by using a forward
> declaration of the form
> template< class T > struct is_pod;
> in the appropriate namespace, like boost::core_type_traits, and then
> adding his specializations:
> template<> struct is_pod< blank >
> BOOST_STATIC_CONSTANT( bool, value = true );
> without including ANY additional headers.
> If we look at the current implementation of Boost.TypeTraits, for
> example is_pointer, we see this:
> template< typename T >
> struct is_pointer_impl
> BOOST_STATIC_CONSTANT(bool, value =
> , ::boost::type_traits::ice_not<
> in namespace detail, and then this:
> which takes care of everything else.
> Note that is_pointer_impl is EXACTLY what we need! It is the core
> implementation of the trait and exposes only ::value and nothing else.
> The full-featured boost::is_pointer is built on top of that.
> If detail::is_pointer_impl was called core_type_traits::is_pointer,
> this would immediately take care of the two problems at the top of
> this post, while not affecting the users of Boost.TypeTraits in any way.
I like this proposal. However, I'm wondering if
BOOST_TT_AUX_BOOL_TRAIT_DEF1 is so heavy so that it can not be on
But how this split would get ride of the MPL dependency? I suspect that
you want common_type to stay in Boost.TypeTraits so that the
Boost.CoreTypeTraits doesn't depend on Boost.Typeof. Couldn't
Boost.TypeOf go also to CoreTypeTraits?
> In particular, note that if a developer specializes
> detail::is_pointer_impl, is_pointer automatically picks up this
You surely mean core_type_traits::is_pointer.
> I propose that a new module, libs/core_type_traits, is created, which:
> - provides core type traits that only expose a member integral
> constant called "value" as part of its documented interface and
> nothing else;
> - allows these traits to be forward declared, without requiring header
> - is not allowed to depend on anything except Config or StaticAssert;
Could CoreTypeTraits depend on Core? Boost.Preprocessor?
> - is the place to which TypeTraits's is_pointer_impls gradually
> migrate, along with their tests.
> - solves the dependency problems some of us are facing,
> - avoids unnecessary code duplication,
> - still allows type trait specialization, with clients of both
> libraries automatically picking up the specialization,
> - is backward compatible with respect to existing uses of
> Boost.TypeTraits because the new library will contain the same code
> and the same tests.
> Thank you for your attention. :-)
Thanks for resurecting this issue,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk