Bruno Dutra wrote
Since the recent discussions regarding MPL and ultimately metaprogramming support in boost, I've engaged in an experimental project, which I believe is close to what you are proposing, I call it MPL2¹. I've been actually inspired by your Library Idea² at Boost Incubator, so my main goal is to start from scratch and provide a drop in replacement for current MPL.
Naturally I'm very pleased whenever someone else likes an idea of mine.
I'm following 3 basic premises:
1. Compatibility shall be restricted to "modern compilers", that is, if a compiler can't handle partial template specializations, template template parameters, non type template parameters or other such basic language features, then it can't handle MPL2.
2. It shall be "C++11 aware", that is, it shall not only take full advantage of C++11 additions, especially variadic templates and template aliases, but also fully support it.
3. It shall be able to replace the original MPL on any existing code without modifications, provided it is compiled on a "modern compiler" in the sense of premise #1.
I would formalize this to "mpl2 is only guaranteed to work on compilers which implement C++11 or higher" rather than "modern compilers".
Backwards compatibility will be provided by a separate include tree which mimics that of current MPL and effectively translates MPL constructs to MPL2 equivalents. ...snip...
Those who need backward compatibility can just use the original MPL. I don't think that the person who takes this on should spend any time at all on it. If you must do it - leave for last when you've got nothing else to do.
I'm also tentatively maintaining compatibility to C++98/03 despite being advised otherwise by some experienced developers
Add me to the list of "advanced developers". There is nothing to be gained by this. Focus in the smallest task which will be useful to the most people. If you feel you must address older compilers - do it later when everything else is done.
Furthermore, I've bought the idea that metafunctions are rather dissociated from containers, so I've split the include tree into two main trunks, currently called core, containing general metafunctions, and sequences for the rest.
as I said before. my current thinking is that one should make two separate smaller and simpler libraries: a) metafunctions - depends upon nothing except perhaps the C++11+ standard library b) typelists - depends only metafunctions. Get metafunctions done (including tests and documentation) before moving to to typelists. Or better yet, hope that someone else is inspired by your efforts to take typlists up on their own. This would be ideal from my perspective.
Now onto some MPL features I plan to improve on MPL2:
...snip ...
You're getting way off track here. The problem is: MPL is very large and cumbersome, difficult to understand and maintain, too hard to understand. Fix this problem before you think of going on to other problems! Actually it would be very useful to fix half the problem - metafunctions. Fix this problem before going on to anything else.
Finally I must add development is still at the very beginning and the resources available to me, essentially time, is rather scarce, but I'm seriously committed to bringing it about, so please don't give up on me :)
Follow my advice. Make something large enough to be useful but no larger. Much better to have something people use than something that doesn't get done. The smallest useful subset of MPL is going to be a lot more work than you're currently expecting. Robert Ramey PS, I'm to go update my "suggestion" at http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ to reflect my later thinking on the subject. RR -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4673934.html Sent from the Boost - Dev mailing list archive at Nabble.com.