Re: [boost] [type_traits][core] modularisation and moving stuff about (again)

Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-08-22 20:51:18

On Wed, Aug 22, 2018 at 9:18 PM, Glen Fernandes via Boost
<boost_at_[hidden]> wrote:
> 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.