typedef apply1< add_const<_1>,int >::type t; // t == int const
</pre>
<p>With these two modifications, now the compiler that has been barking at us now
happily accepts it. "Hey, that's not that bad at all!" you might say. Just put a
little macro inside and be happy again.</p>
</div>
<divclass="section"id="limitations">
<h2><aname="limitations">Limitations</a></h2>
<p>Unfortunately, that's not quite the end of the story. There are
still cases where the above approach will fail and we will have to
resort to writing out-of-line metafunction class. Here are the
details:</p>
<blockquote>
<p>To make the lambda expression work without partial template
specialization and
template template parameters, the MPL has to implement some other way of
pulling apart the template instantiations' expression tree, and the only way
to do it is through an intrusive metafunction introspection
mechanism. That's what hidden behind the <ttclass="literal"><spanclass="pre">BOOST_MPL_AUX_LAMBDA_SUPPORT</span></tt> macro
we've seen above.</p>
<p>But then, after we've got the information we need (the metafunction's arity
and its exact template arguments) stored inside the metafunction itself,
the only way for the library to access it is to look inside the metafunction.
The latter, in its turn, means instantiating the metafunction, prematurely,
before the actuall call, <em>with one or more placeholder arguments</em>. This last
part is a potential problem.</p>
</blockquote>
<p>In other words, the mechanism works as long as your metafunction is
"placeholder-safe" (can be safely instantiated on placeholder
arguments), which comes down to the follwing two criteria:</p>
<olclass="arabic simple">
<li>The metafunction doesn't access its arguments' nested members, or</li>
<li>The only accessed members are types named <ttclass="literal"><spanclass="pre">::tag</span></tt> or <ttclass="literal"><spanclass="pre">::type</span></tt> (the
placeholders do contain these).</li>
</ol>
<p>If these two hold, you can safely put <ttclass="literal"><spanclass="pre">BOOST_MPL_AUX_LAMBDA_SUPPORT</span></tt> inside
your metafunction and forget about the issue. If not, your are out of luck and
probably have to write a metafunction class instead.</p>
<p>The good news are that most of the MPL's own metafunctions and <aclass="reference"href="../../../type_traits/index.html"target="_top">Boost.Type Traits</a>
templates are "placeholder-safe" and have the workaround applied to them, so
even on broken compilers things "just work" in about 90% of use cases.</p>
<p>Please refer to the MPL <aclass="reference"href="./reference-manual.html">reference manual</a> for the details on the
