THE BOOST MPL LIBRARY: apply/lambda Semantics

Front Page / Changelog & History / Changes in Boost 1.32.0 Release / apply/lambda Semantics

# `apply`/`lambda` Semantics

1. Nullary metafunction classes are now consistent with all other metafunction classes, rather than being identical to nullary metafunctions:

   Nullary... | Before | Now
   --- | --- | ---
   Metafunction | `f::type` | `f::type`
   Metafunction class | `c::type` | `c::apply<>::type` or `c::apply::type` [7]

   This fixes a flaw in the metafunction class/metafunction algebra that long has been a major source of other inconsistencies throughout the library.

2. The `apply` metafunction now automatically invokes `lambda` on its first argument. For example, the following is well-formed now:

       typedef apply< plus<_1,_1>, int_<2> >::type four;

   `apply_wrap`n auxiliary metafunctions are available for rare cases when it's crucial to eliminate the small overhead associated with lambda expressions while still avoiding various compiler bugs known to cause problems with the obvious `f::template apply<...>::type` syntax.

3. The `lambda` implementation for broken compilers has been reworked to emulate the semantics of the full-fledged version as closely as possible; consequently, any code out there that was taking advantage of the semantic quirks of less complete emulation in the previous release may stop working with the new one.

To get a detailed picture of the new apply/lambda semantics, please see the test case at http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/apply.cpp?view=markup and the corresponding sections of the MPL reference manual.

[7] | The second form is available only on fully conforming compilers.