Re: [boost] [mpl] Merging 'develop' to 'master'

Subject: Re: [boost] [mpl] Merging 'develop' to 'master'
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-03-20 07:53:42

On 3/20/2014 6:00 AM, Daniel James wrote:
> On 19 March 2014 22:55, Edward Diener <eldiener_at_[hidden]> wrote:
>
>> I would like to merge the mpl 'develop' changes to mpl 'master'. The
>> develop changes have cycled long enough IMO for the merge to take place,
>> without any problems showing up in the changes. There are two changes of my
>> own and a number of Stephen Kelly eliminating support for very old compiler
>> versions. The changes will clean up many obsolete workarounds for older
>> versions of compilers that no one doing template metaprogramming should
>> seriously use anymore. My own two changes fix some minor problems I ran
>> into when testing clang with VC++ RTL on Windows. The changes make the MPL
>> easier to understand. If there are no objections to the merge I will be
>> glad to carefully do it myself, or Dave Abrahams/Alex Gurtovoy or others
>> who have write access to MPL can do it. But I think it is important to get
>> these changes into 'master', and tested in the 'master' regression tests,
>> before the next Boost release.
>>
>
> I'm in the middle of cleaning up MPL's history, so please don't anything at
> the moment. You can see what I'm doing at:
>
> https://github.com/boostorg/mpl/pull/2
> https://github.com/boostorg/mpl/pull/3
>
> But also I object because I don't think that we can safely make significant
> changes to MPL. I recently discovered that a change to type traits had
> broken several libraries, and no one noticed; changes to MPL have similar
> problems. Our test results are a mess, and no one is monitoring a lot of
> them, so updating libraries with lots of dependants is tricky.

In this case we can't put out a Boost release if no one is monitoring 
test results for their library.

I have been monitoring test results for MPL on 'develop' and none of the 
changes is causing any problems with the MPL tests.

> Especially
> since there are a lot of outstanding changes in those dependants' develop
> branches. On top of that mpl is complicated and weird, so it's hard to
> review any major changes. And there are people who rely on MPL on compilers
> that we don't test.
>
> I also don't see much gain from making the code simpler when no one is
> implementing anything new. The gains have to be significant to justify the
> risk.

Maybe no one is implementing anything new because the code is 
complicated ( supporting old compilers which no one uses anymore ).

>
> Right now, I think the best approach to MPL is to only allow bug fixes.
> People doing metaprogramming are moving on to using C++11 features, which
> MPL doesn't serve particularly well, so I think we should be in the process
> of managing its decline, and be more concerned with old code that relies on
> it.

The changes made by Stephen Kelly got rid of support for VC6, VC7 ( 
VS2002 ) and old versions of gcc ( prior to gcc-4 I believe ).

I do want to update MPL at least with my fixes, so please tell me when 
you are finished cleaning up MPL's history.