I am using BOOST_MPL_ASSERT to assert a lambda-expression applied to a sequence of types by folding the lambda-expression onto a sequence of types (see code and continue discussion below). template struct mpl_assert { typedef typename apply::type type; BOOST_MPL_ASSERT((type)); }; template struct assert_for_all : foldr< mpl_assert, true_, xs

{};

The foldr metafunction is a strict version of Haskell's foldr, i.e., MPL's reverse_fold with parameters passed in the order that Haskell's foldr passes parameters. The distinction isn't important for this discussion, so don't dwell on that detail. My intent is that if the lambda-expression is false for one of the types in the sequence, then the lambda-expression applied to the "bad" argument is printed in a compile-time error. However, what gets printed is the result of the lambda-expression applied to the bad argument: integral_constant, which is very uninformative. If the definition of mpl_assert is changed to the following: template struct mpl_assert { typedef typename apply::type type; BOOST_MPL_ASSERT((apply)); }; ...then what gets printed is the unevaluated application of a lambda-expression to the bad argument. While this is more informative, it is still too messy because the type is a lambda-expression containing placeholders. The most desirable type to have printed would be the lambda-expression after placeholder substitution, but before further evaluation. For example, imagine: typedef assert_for_all, boost::mpl::vector

::type type;

...the first definition of mpl_assert prints the following uninformative type in the displayed error: boost::integral_constant ...the second definition of mpl_assert prints the more descriptive but overly messy type: boost::mpl::apply, foo, mpl_::arg<-0x000000001> >, 0>, bar, mpl_::na, mpl_::na, mpl_::na, mpl_::na> ...but what I want to have printed is the type: boost::is_same Boost.MPL is already calculating such a type, because apply, bar> returns is_same::type, so the needed type is there... but does Boost.MPL provide a means of accessing it as opposed to accessing its ::type field?