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. [...] 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.
That's exactly the point I was trying to make. Hana is awesome, but it doesn't fit as a replacement for MPL, simply because it was meant for a different purpose. I see no reason why they shouldn't live side by side, each filling its specific niche.
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. [...] One thing that might be useful would be to set an explicit policy like "MPL is only guaranteed to works with: MSVC 8.0 and above GCC ?? and above etc.
That is certainly an audacious idea, but I don't see a better way of seriously revamping MPL either. I think that was precisely the original intention of Louis Dionne's MPL11, which ended up deviating its course and dropping backward API compatibility. Quoting from MPL11 github page: "This was initially supposed to be a simple C++11 reimplementation of the Boost.MPL. However, for reasons documented in the rationales, the library was redesigned and the name does not fit so well anymore." Perhaps it would be easier to just start off MPL11 and reintroduce backward compatibility than to start anew. I wouldn't go so bold as to assert I'm up to the task, but I take it as a great opportunity for learning and amusing myself, so I'll look into it at the slow pace my busy life allows me. That said, I'm with Edward Diener in believing there's lots of room for improvement in the library as it is and that one should not be afraid of pushing it forward bit by bit. I understand the concerns regarding breaking compatibility for older setups, but aren't there volunteers who run test suites daily, precisely to assure everything is working as expected across the various setups? One thing that I noticed though, is that MPL test suite right now does not cover anywhere near even the documented API, let alone corner cases which should definitely be tested (running algorithms on empty sequences comes to mind). A bugfix on which I'm working right now, for instance, would have been caught a decade ago, had tests been written to cover the fact, which is explicitly written in the documentation, that insert_range should work for "Extensible Associative Sequences". As soon as I get this bug fixed (which is taking way longer than it should, I must admit), I'll work on expanding current test cases based on the documentation and file a pull request for that. I just count on you boost maintainers to help me out by reviewing and accepting my pull requests as appropriate :) -- *Bruno C. O. Dutra*