Re: [boost] A proposal for the creation of a new module, Core Type Traits

Subject: Re: [boost] A proposal for the creation of a new module, Core Type Traits
From: John Maddock (boost.regex_at_[hidden])
Date: 2015-01-08 12:39:25

>> > These two problems could be avoided if we were to have core type
>> traits > whose interface consisted solely of a member integral
>> constant called > "value", without any other required members or base
>> classes, and which > were only allowed to depend on Config or
>> StaticAssert.
>>
>> I'm less keen on this because it fractures the lib into two
>> conceptually different parts.  Let me mess around with some code and
>> see if something better is possible.
>
> As I tried to explain further down, it simply separates the two already
> existing layers in the library: the part that computes the value of the
> trait, which results in something like is_pointer_impl<T>::value, and
> the part that defines the trait, which is generally implemented like this:
>
> BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_pointer,T,::boost::detail::is_pointer_impl<T>::value)
>
>
> This separation is natural, in that the library already does it.
>
> You're right that some traits will not be able to fit into the core
> part, most obviously common_type. But the users of the core part
> generally do not need them; and for those who do, well, they'll have to
> bite the bullet and use TypeTraits.
>
> Or perhaps I'm missing your point?

I think so - the inner detail layer is exactly that - an implementation 
detail.  It's also a horrible mess that got added when I wasn't looking 
when mpl was added to Boost - that was sort of OK then as it seemed to 
be the only way to make things work, but that's no longer true and 
there's an opportunity here to remove all that obfuscation and crud and 
produce something that's actually halfway readable and maintainable.

But my broader point was that this generates two separate traits called 
is_pod (for example), with slightly different interfaces and conceptual 
requirements on usage.  IMO this is a "really bad thing" and we can do 
much better.

John.