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. 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. This basically amounts to a change of interface. 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. 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.
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. 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 -- View this message in context: http://boost.2283326.n4.nabble.com/mpl-multiset-tp4672187p4672389.html Sent from the Boost - Dev mailing list archive at Nabble.com.