On Wed, Aug 22, 2018 at 9:18 PM, Glen Fernandes via Boost wrote:

On Wed, Aug 22, 2018 at 1:55 PM John Maddock wrote:

...

So... I have a couple of PR's to move some of type_traits into config so it can be used by core.

To be clear, these are intrinsics that we are discussing moving. I believe these in general are better suited for Config, even for other libraries that may not depend on Core but will still depend on Config.

i.e. We're talking about things like BOOST_IS_FINAL(T) which may or may not be defined on a given implementation (e.g. to __is_final(T) or some other implementation specific intrinsic).

A library author might have use for the intrinsic, but not the trait. For example, boost::is_final<T>::value might be false because the implementation has no intrinsic, but that doesn't mean you can derive from T if it really is final. On the other hand, if defined(BOOST_IS_FINAL) then BOOST_IS_FINAL(T) enables that.

I would rather encourage people use type traits, the official interface. Boost.Config or Boost.TypeTraits could provide macros that allow users to detect whether is_final is emulated or is the real deal.

The intrinsic macros aside, whether the traits like boost::is_empty<T> should be in Core is a slightly different question.

I think we should keep stuff where it belongs, if possible. Moving stuff around just because dependencies leaves a real mess where everything is everywhere. Note that dependencies may change as components evolve, so while something seems light right now, it doesn't mean it will remain light in the future.

On Thu, Aug 23, 2018 at 12:38 AM, Glen Fernandes wrote:

On Wednesday, August 22, 2018, Andrey Semashev wrote:

...

I think we should keep stuff where it belongs, if possible.

I agree, in general. The reason we are moving the two macros BOOST_IS_FINAL and BOOST_IS_EMPTY to Boost.Config is because it isn't possible. We want to use them in Boost.Core and Boost.Core cannot depend on Boost.TypeTraits.

Maybe we should make it possible to use Boost.TypeTraits in Boost.Core? I wasn't happy when we duplicated is_same, now this. I'm sure, we'll want more traits in time. Is the restriction of Boost.TypeTraits because it depends on Boost.MPL?

On Wednesday, August 22, 2018, Andrey Semashev wrote:

On Thu, Aug 23, 2018 at 12:38 AM, Glen Fernandes wrote:

...

On Wednesday, August 22, 2018, Andrey Semashev wrote:

...

I think we should keep stuff where it belongs, if possible.

I agree, in general. The reason we are moving the two macros BOOST_IS_FINAL and BOOST_IS_EMPTY to Boost.Config is because it isn't possible. We want to use them in Boost.Core and Boost.Core cannot depend on Boost.TypeTraits.

Maybe we should make it possible to use Boost.TypeTraits in Boost.Core? I wasn't happy when we duplicated is_same, now this. I'm sure, we'll want more traits in time.

Is the restriction of Boost.TypeTraits because it depends on Boost.MPL?

At one point in time. Since Core was established the criteria for for inclusion in it has been "not dependent on any other Boost modules except Core itself, Config, Assert, Static Assert, or Predef." I suppose TypeTraits has changed sufficiently enough now to consider relaxing that... Glen

Andrey Semashev wrote:

Move enable_if to type traits?

We want type_traits to have enable_if anyway, to match std::enable_if, but the problem is that our existing boost::enable_if is not compatible with the standard one. So maybe call the TT one enable_if_ (+ enable_if_t which is fine).

On 08/23/18 14:12, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

For noncopyable, we could convert its detection from is_base_and_derived to a dispatch based on SFINAE.

  // Boost.Core   class noncopyable   {   public:     typedef void _is_boost_noncopyable;   };

  // Boost.TypeTraits   template< typename T, typename = void >   struct is_boost_noncopyable : false_type {};

  template< typename T >   struct is_boost_noncopyable< T, typename T::_is_boost_noncopyable > : true_type {};

This doesn't work because types derive privately from boost::noncopyable, and the trait above returns false in this case.

Does is_base_and_derived (non-intrinsic-based) work with private inheritance?

Andrey Semashev wrote:

...

Does is_base_and_derived (non-intrinsic-based) work with private inheritance?

Yes, it does.

We'll have to do something like #ifndef BOOST_NONCOPYABLE_BASE_TOKEN_DEFINED #define BOOST_NONCOPYABLE_BASE_TOKEN_DEFINED namespace noncopyable_ { struct base_token {}; } #endif then derive noncopyable from that and repeat the above definition where it's used in Type Traits.