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

Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: John Maddock (jz.maddock_at_[hidden])
Date: 2018-08-23 12:16:22

> 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.
>
> 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.

That's sort of true - but we're talking about moving some of them only.  
Also note that use of these macros outside of type_traits is quite 
explicitly not supported - many of them do not map simply to the 
compiler intrinsic, but to the intrinsic plus whatever compiler-specific 
workarounds are required.  And these workarounds require other type_traits.

Now at present the is_final and is_empty intrinsics have no workarounds, 
but I wouldn't rule them out in the future if say the Acme Devastator 
compiler's __is_final dies with some new C++30 compiler feature.

John.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus