On Thu, Aug 23, 2018 at 7:34 AM Andrey Semashev wrote:
On 08/23/18 14:28, Glen Fernandes wrote:
On Thu, Aug 23, 2018 at 7:22 AM Andrey Semashev wrote:
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.
Either in place of, or in addition to (doesn't matter to me) but not the type trait alone. Because the trait alone is inadequate, as I mentioned before.
Then it looks like everything's already in place in Boost.TypeTraits. Why not just use it?
It was established from the first e-mail in this thread that the reason for not taking a dependency on TypeTraits for BOOST_IS_FINAL was purely the restriction on Core not depending on TypeTraits.
(Yes, I remember about circular dependencies; we can solve those, although I don't see it as that much of a problem as the dependency on Boost.MPL would have been.)
Yes. If that restriction is something we're open to relaxing now, that works. Both would allow use of BOOST_IS_FINAL and BOOST_IS_EMPTY in Core and I don't mind where I obtain them from. I'm addressing the following points: - "The macros don't belong in Config": They don't belong in Config only if John doesn't want to maintain them in Config and wants to maintain them in TypeTraits. They're not out of place in Config otherwise. They are macros mapping to compiler-specific features, implemented purely in terms of compiler detection. Config does a lot more compiler-specific detection macros than any other library in Boost. - "Users should only use the type trait": Not if the type trait alone does not satisfy their needs. For example, the point I made about boost::is_final. Either the macro alone or the macro in conjunction with the type trait would be needed. - "The intrinsic macros are not public": They are most certainly public and have been for a long time. If we decide that we can't allow Core to depend on TypeTraits, then (as long as John is still OK with it) we can move them to Config. Glen