Re: [boost] [type_traits] Big changes in develop

Subject: Re: [boost] [type_traits] Big changes in develop
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-05-29 04:01:41

On 28/05/2015 22:14, Peter Dimov wrote:
>> I sketched an implementation along those lines, ...
>
> It's at
>
>    https://github.com/pdimov/common_type
>
> Take a look and let's see how to proceed from there. I haven't yet 
> done the member pointers, which I suspect nobody uses (they aren't 
> covered by the existing tests), but I'll add them later for completeness.
>
> I've applied decay<> up front for simplicity, instead of faithfully 
> doing the reference-preserving work and then throwing that away, which 
> makes a difference in some corner cases, but I doubt that anybody will 
> be able to tell the difference. (Needless to say, those corner cases 
> aren't being tested at the moment.) :-)
>
> Incidentally, why is our decay<> not the same as std::decay? Should it 
> be changed to conform?
>
Yes, I fixed that yesterday, see

https://svn.boost.org/trac/boost/ticket/7760 andhttps://github.com/boostorg/type_traits/commit/d3ac8b95c4cbc8876746b573daf3fa60446cfd27.

Does that render remove_cv_ref more or less redundant?

Also noticed in your code, how easy is it to extend to other built in arithmetic types?  We should support __int128 and __float128 when available for example (|BOOST_HAS_INT128, no Config macro for __float128 yet, though Math has it's own one)|.

And while you're on a roll.... can you see how to fix https://svn.boost.org/trac/boost/ticket/7544?  common_type should have member ::type only when such a common type exists.

But this looks to be a much cleaner approach than what we have now, as well as junking those pesky dependencies.  Nice work!  John.