Subject: Re: [boost] New dependency report
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-15 08:17:07
On Sunday 15 June 2014 13:47:22 Vicente J. Botet Escriba wrote:
>
> Let me know IIUC: are you proposing Core true_, false_ types that can be
> used by TypeTraits and MPL preserving backward compatibility?
My personal preference is slightly different. I'll rehash:
1. Separate MPL into MPL and MPL.Core, as I've done in my private repos.
2. Make MPL.Core not depend on TypeTraits. There is only one dependency now,
which is only needed to work around Borland bugs.
3. Separate TypeTraits into TypeTraits and TypeTraits.Core. TypeTraits.Core
should ideally not depend on MPL and MPL.Core. It may require MPL.Core for
things like mpl::if_, mpl::and_, etc, although the necessary components may be
duplicated or implemented differently. At this moment, I have no strong
opinion whether the dependency on MPL.Core should be strictly avoided. I'm
certain though that TypeTraits.Core will not derive from any primitives, std::
or MPL.Core. TypeTraits will depend on MPL (this will be needed for
common_type). At least initially, TypeTraits will still derive from MPL.Core
primitives and provide backward compatibility.
4. Further improve MPL.Core for compatibility with std::integral_constant and
also support Peter's proposed conversion constructor in mpl::bool_.
I would prefer not to put anything from MPL into Core. I would accept a re-
implementation of std::integral_constant in Core (for compatibility with C++03
compilers); a simple using std::integral_constant; into boost:: would be one
possible implementation. MPL.Core then could derive its primitives from
boost::integral_constant, this way providing compatibility with std:: numeric
constants. Note that TypeTraits would gain support for tag dispatching on
std::true_type and false_type as soon as this is done.
I think that any version of TypeTraits that does not derive from MPL.Core
primitives has to be announced as an alternative implementation (I call it
TypeTraits v2), possibly deprecating the current one. This means that the two
versions will have to coexist in Boost for some time. Arguably, both can be
based in TypeTraits.Core.
> Just to clarify my concern, the documentation of TypeTraits doens't
> preclule any dependency to MPL types and any module using this
> implementation detail should be fixed or we need to update the
> TypeTraits documentation.
Deriving from MPL primitives is documented.
http://www.boost.org/doc/libs/1_55_0/libs/type_traits/doc/html/boost_typetraits/mpl.html
Note that my above plan implies swapping integral_constant and MPL primitives
in the inheritance chain. This alone can be viewed as a breaking change on its
own, although I'd say it's a relatively safe one.