Hi Larry,
I'm not saying there's a bug in either. I'm claiming there's a documentation bug.
You are right, please see below.
Finally, when you use a lambda expression inside another lambda expression, you need to wrap it in protect. mpl::apply<mpl::apply<op_meta_fun_elem<_1, _2>, _1, mpl::deref<_2> >, state0, iter0>::type is guaranteed to behave strangely, because all the placeholders will be substituted by the outermost apply.
So the documentation in fold.html should have used protect somewhere in apply<op,_1, deref<_2> >?
Nope, it should have been typedef iter_fold<s,state,apply2<lambda<op>::type,_1,deref<_2> > >::type t; ^ ^^^^^^^^^^^^^^^^ That is: - 'apply2' instead of 'apply' to workaround "apply + lambda + BOOST_MPL_LIMIT_METAFUNCTION_ARITY+1" issue (http://article.gmane.org/gmane.comp.lib.boost.user/9917) and - 'lambda<op>::type' instead of 'op' to prevent 'op' from being treated as an integral part of the 'apply2< ...,_1,deref<_2> >' lambda expression. Fixed in the doc sources in the trunk (https://svn.boost.org/trac/boost/changeset/51791). Thanks for the report! -- Aleksey Gurtovoy MetaCommunications Engineering