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.