Andrey Semashev wrote:
I was thinking you were proposing a replacement for deriving traits from bool_.
More precisely, I was proposing a way for code that dispatches on bool_ to not require derivation from bool_. So that a library can use a core type trait (that does not derive from anything) and core::bool_ to dispatch in the same way it did before. This is not a magic replacement. It still requires source changes.
My point was that your proposed bool_ doesn't fully reflect the current interface, so it can't replace it. In that case, is there a point to it?
Maybe. It depends. The point is that there are two general types of MPL dependencies: libraries that do use metaprogramming facilities, and libraries that only use bool_, if_, and_, and similar things. If these things exist in Core, a library of the second kind can drop its MPL dependency. Of course, if these facilities are split into 'mpl_core', this will considerably lessen the need for duplication in 'core'. Duplicating in 'core' has the advantage of not worrying about backward compatibility so we can avoid the no longer necessary workarounds and (ideally) offer the simplest and most straightforward implementation. And not duplicating has the advantage that there's no duplication. :-)
TypeTraits will still derive from mpl::bool_.
I'm not sure that our existing type traits need to continue deriving from mpl::bool_. They already derive from boost::integral_constant, which is expected to provide ::type as that's a requirement on std::integral_constant. On the other hand, there are likely many uses of type traits in an MPL context and I'm not sure what places, if any, need the ::tag for instance.
We don't need another bool_ in Core (yet) and TypeTraits.Core would be enough for us.
Replacing use of TypeTraits with use of core type traits is precisely what demands the use of another bool_, because you can no longer use the old mpl::bool_ for dispatching a core type trait. Either we enhance mpl::bool_ with a converting constructor, or we switch to core::bool_.