Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-08-23 11:22:15
On 08/23/18 13:40, Glen Fernandes wrote:
>
> On Thursday, August 23, 2018, Andrey Semashev via Boost
> <boost_at_[hidden] <mailto:boost_at_[hidden]>> 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.