CWG2569 [expr.prim.id.unqual] Use of decltype(capture) in parameter-declaration-clause

[brevzin]

Reference (section label): [expr.prim.id.unqual]

Issue description:

P2036 changed the scope of lambda's trailing-return-type and also tried to clean a few things up with respect to use of capture in certain contexts. The problem with unevaluated use of capture early in lambdas is that we don't yet know if the lambda is mutable and so we don't know how to interpret the capture. The paper made problematic uses of capture ill-formed.

The problem is, there are some uses of such in the wild. As in libstdc++, which has a lambda that looks like this:

[local_end](decltype(local_end) it){ return it != local_end; };

Since P2036 was a DR, this retroactively breaks libstdc++.

While many unevaluated uses of capture can be be problematic -- decltype(f(local_end)) could be, for instance -- this specific case of decltype(unparenthesized-id-that-names-a-capture) is totally fine. We could carve out this specific case to avoid retroactively breaking libstdc++.

Suggested resolution:

Add the carve out to this bullet:

• If either P is in E’s function parameter scope but not its parameter-declaration-clause or the unqualified-id is the expression of a decltype-specifier, then the type of the expression is the type of a class member access expression ([expr.ref]) naming the non-static data member that would be declared for such a capture in the object parameter ([dcl.fct]) of the function call operator of E.

And then change the example:

+ [=]<decltype(x) P>{};         // ok: P has type float
- [=]<decltype(x) P>{};         // error: x refers to local entity but precedes the
+ [=]<decltype((x)) P>{};       // error: x refers to local entity but precedes the
                                // lambda's function parameter scope
  [=](decltype((x)) y){};       // error: x refers to local entity but is in the lambda's
                                // [parameter-declaration-clause](https://eel.is/c++draft/dcl.fct#nt:parameter-declaration-clause)

[jensmaurer]

Is there any reason to single out the decltype-specifier context, or should we allow any unevaluated operand (e.g. sizeof seems fine, too)? And p3.2 in [expr.prim.id.unqual] repeats the negated condition of p3.1 in parentheses, so needs adjustment as well.

[brevzin]

No, that's just the one that Wakely pointed me to. sizeof would work just fine too. Any context in which we know for sure the... mutable-ness... of the lambda would not affect the result. Is there a third one?

Yeah the negated p3.2 case would now be... quite complicated...

[jensmaurer]

noexcept would also work.

But typeid wouldn't, I think, so "unevaluated operand" doesn't quite refer to the right thinig.

[brevzin]

I suppose could introduce a term like (this might not be quite right for sizeof, want to cover sizeof a and sizeof(a) but not like sizeof f(a)):

An unqualified-id is mutable-agnostic if it is either the expression of a decltype-specifier or the operand of a sizeof operator expression.

noexcept would also work (although seems... exceedingly unlikely to be used?)

Which then lets you do the negation slightly nicer:

• If either P is in E’s function parameter scope but not its parameter-declaration-clause or the unqualified-id is mutable-agnostic, then the type of the expression is the type of a class member access expression ([expr.ref]) naming the non-static data member that would be declared for such a capture in the object parameter ([dcl.fct]) of the function call operator of E.

• Otherwise (if P either precedes E's function parameter scope or is in E's parameter-declaration-clause or the unqualified-id is not mutable-agnostic), the program is ill-formed.

[jensmaurer]

CWG2569

The last bullet needs "and", not "or", per rules of boolean logic.
Also, I've swapped the two parts, which seemed easier to read.

[cor3ntin]

@brevzin Thanks for creating this issue, I was about to send a mail to core. We also had one such instance in LLVM.
I suspect part of the issue is that generic lambda were not available in c++11, and so decltype might have been used to work around that.
I will implement the remediation, which seems reasonable

[cor3ntin]

On second thought, what is the criteria to determine what a mutable-agnostic expression is?
Would anything be lost if decltype was the only special case here? Do we really think allowing sizeof in particular is useful? (The implementation can get hairy)

[jensmaurer]

Well, sizeof seems not much different from decltype: If you know the type, you should also know its size. And the type is complete,because it's a capture.

For me, the criterion for "mutable-agnostic" was "unevaluated operand" as a first approximation, except where this doesn't work (e.g. typeid).

[cor3ntin]

There is no design motivation for decltype(x) already beyond "it limits damage to existing code". sizeof and noexcept are even less justified, and not trivial to implement.
More importantly, decltype(x) may not be enough, I just got a report from someone having code doing decltype(*x), and obviously that breaks.
I think we want EWG to look at this and decide if decltype(x) is a sufficient mitigation, and if not, we should seriously consider whether we still want the paper to be a DR (although, breaking code by changing language mode is not much better than doing it unconditionally), and whether we should bite the bullet and allow captures to appear in arbitrary expressions before the end of the parameter list. Sure, it requires some implementation work, but arguably not much more than this proposed resolution, and it would be a lot cleaner - no special casing and no guessing by users as to what is or isn't valid.

[jwakely]

although, breaking code by changing language mode is not much better than doing it unconditionally

It is much better. As it stands, Clang 14 (or any other compiler that implements this DR unconditionally) would be incompatible with all released versions of libstdc++ installed everywhere in the world. Updating the C++ headers on the system is not always an option, or might happen on a slower schedule than updating to a newer Clang that consumes those headers. If it's a C++23-specific change, users have the option to continue using any older mode without problems. If it's unconditional, they don't have that option.

"To use the latest -std option you need updated C++ library headers" is entirely justifiable. Everybody understands that "those headers installed in 2017 do not support C++23 well". But "those headers installed in 2017 are no longer compatible with C++11 mode" is harder to justify.

</vendor>

[jensmaurer]

@cor3ntin, I think just reverting P2036R3 would require a conforming implementation to token-stash the parameter-declaration-clause of a lambda, check for mutable, and then analyze the parameter-declaration-clause for real. That seems like a non-trivial burden. This is not the status quo ante.

Please move further technical discussion here: http://lists.isocpp.org/core/2022/04/12341.php