Re: [boost] MPL and MPL core

Subject: Re: [boost] MPL and MPL core
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-03-30 20:25:53

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.