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

Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-08-23 02:14:10

On 23/08/2018 13:31, Glen Fernandes wrote:
> One thing about this suggestion: If Boost.Config was to provide macros
> that tell users whether Boost.TypeTraits' boost::is_final<T>::value is
> emulated or the real deal, then the compiler detection logic currently
> in Boost.TypeTraits for detecting __is_final would already have to be
> duplicated in Boost.Config. That does not sound like a great idea.
> 
> Right now TypeTraits provides both, which is better. i.e. It provides
> boost::is_final<T>::value and BOOST_IS_FINAL(T). The former uses the
> latter if it is defined, or is always false if not defined.
> 
> If BOOST_IS_FINAL(T) and all its compiler detection logic lives in
> TypeTraits, then that all that compiler detection logic should not be
> duplicated in Config to provide a BOOST_HAS_IS_FINAL_INTRINSIC or
> similar feature detection macro.

What if Boost.Config contained all the compiler detection logic to 
define BOOST_HAS_IS_FINAL_INTRINSIC or not, and then Boost.TypeTraits 
had no detection and simply used BOOST_HAS_IS_FINAL_INTRINSIC to then 
define BOOST_IS_FINAL and boost::is_final<T> appropriately?

That seems like a more appropriate division of responsibilities to me. 
(Unless I'm missing something about the implementation, which I haven't 
examined.)

Although granted this doesn't solve Boost.Core wanting to use is_final, 
unless it's allowed to use TypeTraits, or unless it just wants 
BOOST_HAS_IS_FINAL_INTRINSIC and not the full trait.