Re: [boost] [type_traits] Modularization proposal

Subject: Re: [boost] [type_traits] Modularization proposal
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-09-16 21:27:08

On September 16, 2014 3:47:32 PM EDT, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
>On Tuesday 16 September 2014 20:06:27 John Maddock wrote:
>> > 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)?
>
>Hmm, I didn't notice that header. Ok, assuming we don't want to move
>this one 
>header to its own sublib, what if we approach it from the other side.
>We can 
>move all type traits except common_type.hpp and type_traits.hpp to a
>sublib 
>base (i.e. type_traits/base). floating_point_promotion.hpp would be
>changed to 
>not depend on MPL before moving to base.

This seems almost ridiculous. If one can choose to not include the headers that incur the dependencies, then one can avoid then when desired. Those that don't care will just include boost/type_traits.hpp.

___
Rob

(Sent from my portable computation engine)