Boost logo

Boost :

Subject: Re: [boost] MPL and MPL core
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-04-01 11:15:39

2015-04-01 10:13 GMT-03:00, Louis Dionne <ldionne.2_at_[hidden]>:
> Why would you want an MPL replacement when you could have much better?

Well, why would you want much better if you can have much simpler? :)

> If you're going to go for C++11/14 anyway, why in heaven would you want to
> stick to the MPL?

There seems to be a misconception that MPL is utterly outdated and old
fashioned, but I beg to differ. I find myself increasingly fond of its
design and I particularly like how well it mimics STL. In my opinion,
that is precisely one of its greatest strengths.

> I could understand a 100% backward compatible C++03
> overhaul of the current MPL, which would give you
> 1. Improved compile-time and error messages in __existing__ code
> 2. Easier to maintain MPL codebase

These were exactly the arguments which initially motivated me to start MPL2.
I had failed to realize then, however, that existing code should
usually compile just fine on modern compilers too and, therefore,
could certainly benefit of MPL2 even if it were to drop compatibility
to C++03. See, I don't think developers usually chose to enforce
C++03, I mean, they might very well prefer coding in a more
traditional way and not use C++11 features, but that does not require
support for newer features to be strictly disabled on modern
compilers. Let us not forget C++11 is backwards compatible.

> However, I do not see a justification for sticking with the MPL when
> writing new code. Anyway, if you (Bruno) still want to go down this
> path, which has been beaten, please at least do not start from scratch.
> I would suggest you fork the MPL11 around the commit at [2], which
> is an almost complete backward-compatible implementation of the MPL
> for C++11. It even has iterators and all that stuff. You can contact me
> off-list regarding this if you want.
> Regards,
> Louis

As I said before, and I think at least Robert has expressed a very
similar view of this matter, sometimes the user just needs basic type
computations and would rather not spend time developing it
her/himself. For such use cases I believe MPL excels and might thus be
prefferred. At any rate, I don't think MPL would ever compete with
Fusion or Hana, simply because they all serve for similar, but
definitely different purposes.

I'm also aware you had gone down a very similar path before you
decided to go for something bigger and I'm sure you had justified
motives to do so. However the problem persists, MPL is still left
unmaintained and I'd like to do something about it. All this recurrent
discussions just contribute to strengthen my beliefs that there's
indeed something to gain from a rewriting of MPL and I'll certainly

I really appreciate your help and I'll surely take a look at MPL11,
there's definitelly a lot that could be reused. In fact I'm still to
come up with a decent design for iterators so I'm certainly interested
in taking a look at how you've done it.

*Bruno C. O. Dutra*

Boost list run by bdawes at, gregod at, cpdaniel at, john at