CWG2838 [basic.scope.block] Declaration conflicts with grand-parent and grand-grand-parent scope declarations

[jakubjelinek]

Full name of submitter (unless configured in github; will be published with the issue): Jakub Jelínek

Reference (section label): [basic.scope.block]/2

Link to reflector thread (if any):

Issue description: Is

void foo () {
  auto f = [i = 5] () { int i; return 0; };
}

supposed to be valid after the P2579R0 changes? Before that paper and before P2036R3 this wouldn't be valid, because the capture inhabited the same scope as int i; P2036R3 changed it to inhabit the parameter scope, so parent scope of it and then [basic.scope.block]/2 triggered there. But P2579R0 says that the init capture inhabits lambda scope and isn't that the parent scope of the parameter scope, i.e. grandparent scope of the lambda's compound statement's scope?

And for auto f = [i = 5] <int N> () { int i; return 0; }; it is even grand-grandparent scope.

Suggested resolution:

[jakubjelinek]

Filed this previously as https://github.com/cplusplus/draft/issues/6536

[jakubjelinek]

@jicama, @cor3ntin

[t3nsor]

It seems that all versions of GCC and MSVC on Compiler Explorer accept the code, so changing the standard to ban it seems to have questionable value proposition. I mean I think we should have a core issue for this but we should immediately mark it NAD and say "write a paper for EWG" (where you presumably would attempt to quantify the amount of code that would be broken).

[jakubjelinek]

clang rejects it in all versions I've tried.

[jensmaurer]

CWG2838

[cor3ntin]

@t3nsor I would not agree with NAD, but this does somewhat sound like an ewg question, we could send them this issue. (although, as @jakubjelinek mention, this is an unintended consequences of P2036R3, and in that light, we should maybe restore the behavior prior to that paper.