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

On 08/23/18 13:40, Glen Fernandes wrote:

On Thursday, August 23, 2018, Andrey Semashev via Boost mailto:boost@lists.boost.org> wrote:

What if the compiler intrinsic doesn't work in some cases? Boost.TypeTraits apply workarounds for such cases, so that the official trait works as intended. These workarounds might be impossible or expensive to do within a macro.

Andrey, the macro is not intended to replace the type trait. Both exist today, both will continue to exist. Users who want to use BOOST_IS_FINAL over boost::is_final will continue to do so. Users who want to use boost::is_empty because of it's workarounds over BOOST_IS_EMPTY will continue to do so. The only thing that would change is where the definition of BOOST_IS_FINAL lives.

I gathered that you intended to use BOOST_IS_FINAL as a way to access a compiler intrinsic, i.e. use it in place of the type trait.

The TypeTraits intrinsic macros are public today and users are using them. They are also all just about compiler detection and mapping to the right intrinsic, nothing more. Them living in Config is not confusing to users, because Config is all about compiler specfic detection anyway.

I didn't find those macros documented. Specifically for BOOST_IS_FINAL, it is mentioned as a *way to detect* whether `boost::is_final` gives the actual result and not just `false`. The docs don't say that BOOST_IS_FINAL is a way to access compiler intrinsics, so if someone is using it this way, he is relying on implementation details.