On 2/19/2015 5:19 PM, Robert Ramey wrote:
Edward Diener-3 wrote
I'm just wondering whether the lack of development of MPL in the past years is just incidental, as developers moved on to new frontiers, or if indeed if reflects a consensus that MPL is obsolete nowadays, which I find hard to believe.
I believe it reflects the fact that the two developers mostly responsible for creating MPL are not very active in Boost anymore.
The mpl library provides functionality which is no where else available and which many boost libraries depend on.
I believe that the fact is that no one is responsible for it anymore.
Just eliminating a few hacks in it is not the same as taking responsibility for it.
You are right about this. But MPL is a large library and it should not need total comprehension for a Boost developer to make changes to a small part of that library if the changes made improve MPL in some way.
A while back Stephen Kelly specified changes to MPL to get rid of hacks for old compilers that nobody should be using anymore, and which would simplify the MPL code a bit so that new development could more easily be done with the code.
This effort had a couple of issues. First it changed the scope of mpl from a library which would support older compilers to one which would limit support to a more modern subset.
Is Boost seriously supposed to support largely obsolete compilers into perpetuity with each new release ? I do not think this is viable in all cases and cannot see this as a goal of Boost libraries. At some point, with some new release, I think it is possible to say for a given library that it does not support a largely obsolete compiler.
This basically amounts to a change of interface.
In the case of Stephen Kelly's removal of old compiler workarounds it does not. The interfaces would have remained the same but hacks to support VC6 and VC7, as well as some other compilers that no one should seriously be using anymore, would have been eliminated. My own feeling is that the improvement in making MPL code more understandable would have easily been worth removing these ancient hacks and the compilers they supported.
Another problem is that making such changes is much, much tricker than first meets the eye. It would be huge effort to do it right.
For the removal of MPL hacks that Stephen Kelly did I believe he got everything right. But since we never got to try it, even in 'develop', we will never know.
The right way would be to:
define MPL2 - a C++11+ version of mpl. Re-implement MPL in terms of C++11. This could skip any part of mpl already in the standard. Presumably it would be a much smaller effort than the original, but it would still be a very large effort. Remember that MPL is the result of efforts of two of the best C++ programmers anywhere. It would be hard to meet that standard. Of course anyone is willing to try, feel free.
That is a much bigger change than what Stephen Kelly had tried to do. That does not mean I do not think it might be worthwhile if someone talented enough and with time enough were to do it.
But these changes were never made and the opinion was voiced that Hana would supercede MPL so why make any changes to MPL itself. I am with you in believing that until a new metaprogramming idiom becomes more popular, such as Hana or maybe Eric's blog contribution.
The jury is still out on these efforts. My concern about hana is that it seems to have evolved way beyond what MPL does and so wouldn't serve as a "drop-in" improvement. I don't know about Eric's effort but I believe he's said he can't bring to the level of a boost library and no one has expressed any interest.
it is worthwhile looking at possible improvements in MPL and it is certainly worthwhile fixing any bug reports which may have been made against MPL.
I can understand the nervousness by which others view any changes to MPL, since it is so heavily used by other libraries and such a core library, but I do not understand the point of view that MPL should remain as frozen as possible so as not to cause problems with other libraries which use it.
I think the main concern is that someone makes a fix - which fixes his problem - but then walks away from it. Then something breaks and the next person does the same thing. That's not the same as having a maintainer take responsibility for it.
If anyone changes anything in a library which breaks anything else it is that person's responsibility to fix things. This is true whether it is MPL or anything else. I agree it would be good to have a maintainer for MPL but a single person trying to take over from Dave and Alexey would be a very difficult responsibility. Still I see nothing wrong with others who have maintainer status with MPL making changes as long as they take responsibility for what they do and of course realize how important and central MPL is to so many other Boost libraries so they must be very careful.
This is an instance of our larger problem of finding a way to keep maintainers for libraries. It's still not even close to being solved.
Robert Ramey