Re: [boost] [type_traits] Modularization proposal

Subject: Re: [boost] [type_traits] Modularization proposal
From: John Maddock (boost.regex_at_[hidden])
Date: 2014-09-16 15:06:27

> Boost.TypeTraits is used in lots of other Boost libraries, and it currently
> unnecessarily pulls MPL and TypeOf. The dependencies are introduced by just
> these two public headers: floating_point_promotion.hpp and common_type.hpp.
> I'd like to avoid these dependencies.
>
> I propose to extract common_type.hpp (and its implementation and tests) into a
> sublib within type_traits (e.g. type_traits/common_type).
>
> As for floating_point_promotion.hpp, it is used in promote.hpp, which is using
> integral_promotion.hpp. I can see two ways of tackling it:
>
> 1. Extract all promotion traits into a sublib (e.g. type_traits/promotion).
> This includes floating_point_promotion.hpp, integral_promotion.hpp and
> promote.hpp, as well as their tests.

What happens to boost/type_traits.hpp in this scheme (which depends on 
*all* of type_traits)?

> 2. Change floating_point_promotion.hpp to not use MPL. MPL is used only to
> workaround BOOST_NO_CV_SPECIALIZATIONS, which is defined for Borland 5.51 and
> older and MPW 8.90 and older. The simplest way is to drop the workaround, but
> at a quick glance it should be possible to retain it.
>
> I'm currently leaning towards the option 2, although we obviously don't test
> those compilers and there is no way of knowing if the code will still work
> after the change. So I'm interested to know others' opinion, both with regard
> to the general idea and the way of proceeding with
> floating_point_promotion.hpp in particular.

+1 on option 2.

John.