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

Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2018-08-23 11:50:36

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