Re: [boost] [type_traits] Time to upgrade to "version 2" ?

Subject: Re: [boost] [type_traits] Time to upgrade to "version 2" ?
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-15 16:20:21

On 5/15/2015 2:09 PM, John Maddock wrote:
> Now that the release is out it's decision time:
>
> I'd like to merge the "Version2" branch of type_traits to develop, it
> passes all the tests, and I've been using it exclusively for testing and
> development locally for a few months now without issues.   But.... it's
> a big change with the potential to break a lot of folks stuff if things
> go wrong given that this is such a core component.  To recap the main
> advantages are:
>
> * Removed all the redundant cruft that's no longer required for
> old/broken compilers we don't support anymore anyway.
> * Very nearly dependency free (other than Config), there's just
> comon_type which still has dependencies elsewhere - and even that
> disappears for a C++11 compiler.
> * Much cleaner, easier to understand code, now that the horrid
> obfuscating macros introduced by MPL have gone.
> * Fewer template instantiations than before as much of the indirection /
> forwarding templates have been removed.
> * As a result code using these headers should be somewhat faster to
> compile - both with fewer template instantiations, and a much lighter
> #include load.
>
> Note that as a result of this change, a number of undocumented headers
> which were none the less being used in Boost have been deprecated.  The
> headers still exist, but warn loud and clear about their deprecated
> status, so folks will get a lot of warnings to begin with.  I know
> Edward Diener has submitted some PR's to fix these, but I plan to make a
> concerted attack on any remaining once the new version is in develop.

A number of those PRs are still sitting there because no one is looking 
to apply them. These include changes for lambda, function_types, and 
iterator.

I applied for administrator rights for lambda and function_types, 
willing to deal with any bug reports and PRs in those libraries since 
neither is being actively maintained, but no one seems to be dealing 
with those requests in boost.admin. Noel Belcourt has replied to me that 
he has been busy but will try to look at iterator.

>
> So here's the question, how do we proceed?
>
> My thoughts are to basically go ahead and merge, but not merge to master
> until after the next release at the earliest to give everything a chance
> to bed down, and the required changes in other libraries to filter
> through.  Or we could have some sort of mini-review either formally or
> informally to check things out before the merge - of course folks are
> most welcome to do this anyway!
>
> Let me know what you think, best, John.

My vote is to go ahead, but I also feel it is important to get PRs which 
eliminate your deprecated warnings message applied so that testing 
output will be smoother. I have detailed the ones I have found  above 
and endeavored to fix with PRs.