Re: [boost] New dependency report

Subject: Re: [boost] New dependency report
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-15 10:30:37

On Sunday 15 June 2014 16:17:07 you wrote:
> 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.

I forgot to add:

3.5. Make MPL depend on TypeTraits.Core. This way we break circular dependency 
between the current MPL and TypeTraits. Note that the circular dependency  is 
broken even if TypeTraits.Core depends on MPL.Core.

> 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_typetra
> its/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.