2015-03-30 21:25 GMT-03:00 Robert Ramey
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".
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.
I do understand it will probably not add much to MPL2, but for some reason I've been reluctant to drop compatibility to C++03, specially now that I've set up this very idiomatic way of writing portable code between standards, I just feel like throwing away so much effort... Oh well, I guess you convinced me to at least postpone it. I'll branch off from what I've got so far and strip every C++03 out of it.
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.
Agreed, MPL should always be around, but since it will be mostly a matter of exposing ::mpl2 to ::mpl directly, it shouldn't take too much time. At any rate, more than just a legacy interface, I see it as a "fit for purpose" test, so indeed I plan to leave it for last.
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.
My initial goal was to rewrite MPL from scratch, diverting from it on just some minor aspects, so that any existing code could promptly be updated to use it, hence the name MPL [version] 2. I do agree it should be split into modules, specially with the coming "C++ modules", but I'm not so sure it would be a good idea to create yet not just one, but two other boost libraries, which would basically replicate MPL. At any rate, as long as I stick to this modularized concept, it should be trivial to split it into two libraries of their own right, should it so be desired in the future, so I'll stick to the idea of keeping both halves integrated into a single library, at least for now.
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.
Granted. What I mean here, is that I already have MPL2 entirely designed in my head and I am confident these two improvements I mentioned will be accomplished the way I've designed it, it is now just a matter of finding time to actually write it and, sure enough, to deal with little caveats I couldn't possibly foresee. I'd like to add I've been using MPL extensively for over a year now on an experimental project¹ I've been carrying out, I have studied its documentation thoroughly, have explored its code in depth seeking to understand its little aspects and even got to issue a couple of pull requests addressing 4 open bug reports, one of which I've actually filed myself, so I do feel confident about bringing MPL2 about. Perhaps I'm just too naive to know it better, time will tell :)
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.
You are absolutely right. I must admit I tend to enlarge my goals to the point I can't possibly achieve it, but the good news are that I am aware of that. I will follow your advice and try not going astray focusing on unimportant matters, beginning by dropping compatibility to C++98/03. Oh and do let me know when you've updated your suggestion at the Boost Incubator. *Bruno Dutra* ¹https://github.com/brunocodutra/metalog