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

2023-01-15


752. Name lookup in nested lambda-expressions

Section: 7.5.5  [expr.prim.lambda]     Status: CD2     Submitter: Daveed Vandevoorde     Date: 10 December, 2008

N2800 comment US 31

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

How does name binding work in nested lambda-expressions? For example,

    void f1() {
      float v;
      []() { return [v]() { return v; } }
    }

    void f2() {
      float v;
      [v]() { return [v]() { return v; } }
    }

According to 7.5.5 [expr.prim.lambda] paragraph 3,

A name in the lambda-capture shall be in scope in the context of the lambda expression, and shall be this or shall refer to a local variable or reference with automatic storage duration.

One possible interpretation is that the lambda expression in f1 is ill-formed because v is used in the compound-statement of the outer lambda expression but does not appear in its effective capture set. However, the appearance of v in the inner lambda-capture is not a “use” in the sense of 6.3 [basic.def.odr] paragraph 2, because a lambda-capture is not an expression, and it's not clear whether the reference in the inner lambda expression's return expression should be considered a use of the automatic variable or of the member of the inner lambda expression's closure object.

Similarly, the lambda expression in f2 could be deemed to be ill-formed because the reference to v in the inner lambda expression's lambda-capture would refer to the field of the outer lambda-expression's closure object, not to a local automatic variable; however, it's not clear whether the inner lambda expression should be evaluated in situ or as part of the generated operator() member of the outer lambda expression's closure object.

Proposed resolution (July, 2009)

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