Boost logo

Boost :

Subject: [boost] A proposal for the creation of a new module, Core Type Traits
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-07 15:20:15

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.

In particular, note that if a developer specializes detail::is_pointer_impl,
is_pointer automatically picks up this specialization.


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;

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at