Re: [boost] MPL and MPL core

Subject: Re: [boost] MPL and MPL core
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-03-29 13:29:14

Andrey Semashev-2 wrote
> On Sunday 29 March 2015 12:43:05 Edward Diener wrote:
>> Were the changes to MPL splitting it between a core and the rest of MPL
>> supposed to be part of the upcoming release ?
> 
> These changes were rolled back. The split version is still available in my 
> fork:
> 
> https://github.com/lastique/mpl/tree/modularization
> 
> 1.58 will contain the monolithic MPL.

I've had occasion to think about this lately.  How about this for an idea:

Create two new libraries:

MetaFunction - would contain the current content of mpl/metafunctions.

Typelists - would contain the current content for mpl/sequences without the
iterator functionality.

Notes:

In order to produce a simpler implementation they would not need to be
backward compatible
with compilers prior to C++11 (or 14 or ...)

I don't think they would need the whole sections of integral constant.

When the implementation can be done in terms of standard library components
or with
boost components - standard library components would be preferred.

The ultimate goal is that these libraries would be attractive for
incorporation into the
standard library to complement type_traits and other stuff which has been
taken from boost.

There is already a lot of "raw material" such as the current mpl, eric's
meta, lorises mpl11, and maybe some other stuff.  Most of the documentation
and tests could almost be transcribed from the current mpl.  So it would be
an "easy" job.

Focus would be not on creating every more powerful functional programming
tools and abstractions, but rather as set of simple, understandable tools
which would make template meta programming more accessible to those of us
who occasionally need it but can't spend a lifetime on it.  Call it TMP for
the rest of us.

I've split it two pieces because I think that these are two orthogonal ideas
and it's much easier to do two smaller things than it is one bigger think. 
I would expect typelists to depend upon metafunctions. 

I very much like the new names because I think they better clearly describe
what they are.

Of course current MPL would e around "forever" but it's usage in newer code
would be discouraged.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4673891.html
Sent from the Boost - Dev mailing list archive at Nabble.com.