Boost logo

Boost :

Subject: Re: [boost] [MPL lite or MPL 2] A modest proposal
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-03-05 10:04:53

Andrey Semashev-2 wrote
> This sounds very similar to the MPL and MPL.Core separation [1]. I
> didn't drop workarounds for old compilers (except for one for
> Borland), but MPL.Core seems to be close to what you list as MPL lite.
> I think it is quite possible to drop the compatibility cruft from
> MPL.Core, although I'm not sure how useful that would be.

That's what (part of) the discussion has been about. Since you're
doing the work and taking responsibility for it, you get to decide
which is the easiest/best way to do it.

> Others have
> stated that newer language features can be used but require a
> reimplementation. That's probably true, although I'm quite happy with
> the current MPL.Core interface

I would like to make a clear distinction between interface and
implementation. MPL Core/Lite MUST support the the current
interface. If convenient and/or useful, the interface could
be expanded (but then you'd have to update the documentation
and tests). But the implementation could take advantage
of modern C++ and wouldn't be required to be compatible with any
compiler which doesn't support C++11+. So presumable this
would be much easier than the current MPL

> (note - not the iterators stuff, which is not part of MPL.Core).

My view is that the concept of type lists (sequences) is orthogonal
to metafunctions. I think dividing MPL into two separate
libraries would leave us with something easier to understand
and maintain and would also reduce dependencies. So instead
of having one very large complex library for which we're unable
to find a maintainer, we'd have two large complex libraries for
which we'd be unable to find maintainers. Is that progress? I
think so.

Also, I think that we could evolve to this solution without being
overly disruptive.

View this message in context:
Sent from the Boost - Dev mailing list archive at

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