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.