Re: [boost] MPL and MPL core

Subject: Re: [boost] MPL and MPL core
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-03-30 23:17:59

2015-03-30 21:25 GMT-03:00 Robert Ramey <ramey_at_[hidden]>:

> > 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