On Wed, Aug 22, 2018 at 9:18 PM, Glen Fernandes via Boost
On Wed, Aug 22, 2018 at 1:55 PM John Maddock wrote:
So... I have a couple of PR's to move some of type_traits into config so it can be used by core.
To be clear, these are intrinsics that we are discussing moving. I believe these in general are better suited for Config, even for other libraries that may not depend on Core but will still depend on Config.
i.e. We're talking about things like BOOST_IS_FINAL(T) which may or may not be defined on a given implementation (e.g. to __is_final(T) or some other implementation specific intrinsic).
A library author might have use for the intrinsic, but not the trait. For example, boost::is_final<T>::value might be false because the implementation has no intrinsic, but that doesn't mean you can derive from T if it really is final. On the other hand, if defined(BOOST_IS_FINAL) then BOOST_IS_FINAL(T) enables that.
I would rather encourage people use type traits, the official interface. Boost.Config or Boost.TypeTraits could provide macros that allow users to detect whether is_final is emulated or is the real deal.
The intrinsic macros aside, whether the traits like boost::is_empty<T> should be in Core is a slightly different question.
I think we should keep stuff where it belongs, if possible. Moving stuff around just because dependencies leaves a real mess where everything is everywhere. Note that dependencies may change as components evolve, so while something seems light right now, it doesn't mean it will remain light in the future.