Lambda capture and parameter with same name – who shadows the other? (clang vs gcc)

by

Update: as promised by the Core chair in the bottom quote, the code is now ill-formed:

If an identifier in a simple-capture appears as the declarator-id of a parameter of the lambda-declarator‘s parameter-declaration-clause, the program is ill-formed.

There were a few issues concerning name lookup in lambdas a while ago. They were resolved by N2927:

The new wording no longer relies on lookup to remap uses of captured entities. It more clearly
denies the interpretations that a lambda’s compound-statement is processed in two passes or that any names in that compound-statement might resolve to a member of the closure type.

Lookup is always done in the context of the lambda-expression, never “after” the transformation to a closure type’s member function body. See [expr.prim.lambda]/8:

The lambda-expression‘s compound-statement yields the function-body ([dcl.fct.def]) of the function call operator, but for purposes of name lookup, […], the compound-statement is considered in the context of the lambda-expression. [ Example:

struct S1 {
  int x, y;
  int operator()(int);
  void f() {
    [=]()->int {
      return operator()(this->x+y);  // equivalent to: S1::operator()(this->x+(*this).y)
                                     // and this has type S1*
    }; 
  }
};

—end example ]

(The example also makes clear that lookup does not somehow consider the generated capture member of the closure type.)

The name foo is not (re)declared in the capture; it is declared in the block enclosing the lambda expression. The parameter foo is declared in a block that is nested in that outer block (see [basic.scope.block]/2, which also explicitly mentions lambda parameters). The order of lookup is clearly from inner to outer blocks. Hence the parameter should be selected, that is, Clang is right.

If you were to make the capture an init-capture, i.e. foo = "" instead of foo, the answer would not be clear. This is because the capture now actually induces a declaration whose “block” is not given. I messaged the core chair on this, who replied

This is issue 2211 (a new issues list will appear on the open-std.org site shortly, unfortunately with just placeholders for a number of issues, of which this is one; I’m working hard to fill in those gaps before the Kona meeting at the end of the month). CWG discussed this during our January teleconference, and the direction is to make the program ill-formed if a capture name is also a parameter name.

More Related Contents:

  1. A positive lambda: ‘+[]{}’ – What sorcery is this? [duplicate]
  2. Capturing a reference by reference in a C++11 lambda
  3. Can using a lambda in header files violate the ODR?
  4. What is a lambda expression in C++11?
  5. Has C++ standard changed with respect to the use of indeterminate values and undefined behavior in C++14?
  6. Is it possible to figure out the parameter type and return type of a lambda?
  7. C++11 does not deduce type when std::function or lambda functions are involved
  8. Recursive lambda functions in C++11
  9. How to convert a lambda to an std::function using templates
  10. Is the size of std::array defined by standard
  11. Using member variable in lambda capture list inside a member function
  12. Capturing perfectly-forwarded variable in lambda
  13. In C++11, does `i += ++i + 1` exhibit undefined behavior?
  14. Inferring the call signature of a lambda or arbitrary callable for “make_function”
  15. I cannot pass lambda as std::function
  16. Lambda capture as const reference?
  17. Lifetime of lambda objects in relation to function pointer conversion
  18. Can C++ code be valid in both C++03 and C++11 but do different things?
  19. How can an incomplete type be used as a template parameter to vector here?
  20. Is left-shifting (
  21. std::remove_if – lambda, not removing anything from the collection
  22. Lambda functions as base classes
  23. Is writing to &str[0] buffer (of a std:string) well-defined behaviour in C++11?
  24. Calling an explicit constructor with a braced-init list: ambiguous or not?
  25. Can we apply content not explicitly cited from the normative references to the C++ standard?
  26. Calling delete on NULL pointers – C++03 vs C++11
  27. std::tuple memory alignment
  28. Rvalues, lvalues and formal definitions
  29. Can I use the result of a C++17 captureless lambda constexpr conversion operator as a function pointer template non-type argument?
  30. What is use of the ref-qualifier `const &&`?

Leave a Comment