This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

762. Name lookup in the compound-statement of a lambda expression

[Voted into the WP at the July, 2009 meeting as part of N2927.]

The current wording of 7.5.6 [expr.prim.lambda] is not clear as to how name lookup is to be performed for names appearing in the compound-statement of a lambda expression. Consider, for example:

    int fac(int n) {
      return [=]{ return n <= 1 ? 1 : n*operator()(n-1); }();
    }

There is no operator() in scope in the context of the lambda expression. Consequently, according to bullet 5 of paragraph 10, the reference to operator() is not transformed to the class member access syntax but appears untransformed in the closure object's function call operator, where presumably it is interpreted as a recursive call to itself.

A similar question (although it does not involve name lookup per se) arises with respect to use of this in the compound-statement of a lambda expression that does not appear in the body of a non-static member function; for example,

    void f() {
      float v;
      [v]() { return v+this->v; }
    }

this cannot refer to anything except the closure object, so are the two references to v equivalent?

The crux of this question is whether the lookups for names in the compound-statement are done in the context of the lambda expression or from the call operator of the closure object. The note at the end of bullet 10.5 would tend to support the latter interpretation:

[Note: Reference to captured variables or references within the compound-statement refer to the data members of F. —end note]

Another possible interpretation of the current wording is that there are two distinct compound-statements in view: the compound-statement that is part of the lambda-expression and the body of the closure object's function call operator that is “obtained from” the former. If this is the intended interpretation, one way of addressing the issues regarding the operator() example above would be to state that it is an error if the lookup of a name in the compound-statement fails, making the example ill-formed.

Proposed resolution (July, 2009)

See document PL22.16/09-0117 = WG21 N2927.