On 3/20/2014 6:00 AM, Daniel James wrote:

On 19 March 2014 22:55, Edward Diener 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.

On 3/20/2014 6:39 PM, Daniel James wrote:

On 20 March 2014 11:53, Edward Diener wrote:

...

On 3/20/2014 6:00 AM, Daniel James wrote:

...

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.

The problem is that many libraries don't have a maintainer. I suspect most maintainers only check the test results periodically, possibly only when they're making changes themselves.

This is a separate issue that impacts Boost putting out a release. I think some system by which a library maintainer(s) indicate that he has checked the regression tests at xxx date would be really helpful, else the burden to make sure changes are still passing regression testing will not be met. Furthermore every library needs a maintainer of some sort, whether individually or by committee.

I have been monitoring test results for MPL on 'develop' and none of the

...

changes is causing any problems with the MPL tests.

I'm sure you're doing everything you can, but what I'm worried about is problems that won't show up in the MPL tests. The overall tests results are such a mess, that it's infeasible to get any idea about boost as a whole from them, and new failures are easily missed.

I hear this, but until the test results are cleared up Boost should not put out a new release anyway. Problems could be from the MPL changes on develop, but that needs to be proved.

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.

I will have to disagree based on my intuition that replacing MPL with something closer to C++11/C++14 constructs is going to be a major undertaking which will not occur in the near future. Furthermore even if/when it occurs numerous Boost libraries would have to transition to the replacement. I do not think we can afford to hold back any needed changes to MPL based on a conservative approach. And removing even the brilliant "hacks" of MPL based on the deficiencies of old, hardly used anymore compilers, will greatly enable whatever changes we might need to make, even if the changes are just mostly cosmetic improvements. Admittedly this is based on my thought that their is no reason, given free gcc, clang, and VC++ express versions, and the current state-of-the-art in C++ compilers in general, that a C++ programmer needs to use obsolete C++ compilers anymore for serious programmer endeavors.

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 ).

They remove support for some other compilers as well. We had an email from someone who still uses Metrowerks which might have problems with the partial template specialization changes.

Should MPL seriously expect to be used by a compiler which still cannot implement partial template specialization correctly ? I do not believe so even if some clever MPL "hacks" currently may allow it. No one even tests Metrowerks AFAIK. Can we really support any compiler which no one tests when that compiler has become so out of date with current C++ ?

I do want to update MPL at least with my fixes, so please tell me when you

...

are finished cleaning up MPL's history.

You're watching the repo on github, so hopefully you should be notified when I merge the pull requests. I'll probably merge them tonight anyway, I'm just going to double check first. They should be okay, since they've all been in either the develop or master for some time.

I think the best thing to do for MPL is to revert Stephen Kelly's changes, and put them on a branch so that they can be reconsidered later. I'm not saying they're bad - at the very least, removing support for old versions of Visual C++ is a good idea. But I think we need to sort out the libraries' dependants first. I'm going to try to start on some of these soon, but it'll take a while.

I pushed a remote/SKChanges branch based on the point of Stephen Kelly's last changes to develop. His changes can currently be reverted on 'develop' without conflicts but I am still loath to do this myself. I would still like to see if his changes on 'develop' are actually causing any problems with other libraries in the 'develop' regression testing.

People doing metaprogramming are moving on to using C++11 features, which MPL doesn't serve particularly well

I don't think C++11 or even C++14 replace enough of the features of MPL. It needs to be updated to take advantage of C++11, but it still serves C++11 pretty well. Plus, it provides a standard mechanism for compile time sequences, metafunction classes, and lambda expressions. Paul Fultz II -- View this message in context: http://boost.2283326.n4.nabble.com/mpl-Merging-develop-to-master-tp4660475p4... Sent from the Boost - Dev mailing list archive at Nabble.com.