"David Bergman" <David.Bergman@bergmangupta.com> writes:
Ok, two interpretations:
1. (Mine) What the MPL documentation calls a "lambda expression" (as of the refered page) is either "placeholder expression" or meta function classes *generated* by the application of mpl::lambda, i.e., *just* the meta function classes generated in that specific way.
It would be perverse, IMO, to call some types lambda expressions only by virtue of how the type was generated. If I write down a type that is exactly identical to mpl::lambda<mpl::identity<_> >::type, but I don't use mpl::lambda to write that type, by your definition it is not a lambda expression. In other words, by your definition: mpl::lambda<mpl::identity<_> >::type is a lambda expression, and yet is_same<mpl::lambda<mpl::identity<_> >::type, x>::value does not imply that x is a lambda expression.
2. (Yours) All metafunction classes are "lambda expressions."
2. is correct.
I am admittedly biased, but I think my interpretation is the most sound one ;-)
The reason for that is that I would hesitate to call an explicitly defined metafunction class, such as
struct MyMeta { template<class T> apply { typedef int type; } };
a lambda expression.
That's a circular reason. You think your interpretation of the meaning of the term is the most sound because you would hesitate to apply the term to such a class. MyMeta is a lambda expression. Consider: template <class T> struct always_int { typedef int type; }; typedef always_int<_1> MyMeta; now MyMeta is again a lambda expression.
I still want to tell my "students" that they should implement a "metafunctor" rather than a "lambda expression," which I consider to be a proper sub set of the former :-)
You are of course free to pick your own terminology, but that's not the "official MPL" terminology and IMO you will just confuse your students, which would be a disservice. -- Dave Abrahams Boost Consulting www.boost-consulting.com