[PATCH] D123909: [Clang] Use of decltype(capture) in parameter-declaration-clause

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added inline comments.


================
Comment at: clang/lib/Parse/ParseExprCXX.cpp:700
+
+  if (Tok.is(tok::identifier) && NextToken().is(tok::r_paren)) {
+    SourceLocation TemplateKWLoc;
----------------
aaron.ballman wrote:
> cor3ntin wrote:
> > aaron.ballman wrote:
> > > This feels surprisingly restrictive to me, but it's sufficient for getting libstdc++ working again.
> > I've can't think of another kind of unqualified-id that could refer to a capturable entity here.
> > Do you know what would be missing?
> > Also, without being very restrictive, I'm not sure how this is implementable
> What I find restrictive is that it requires an unqualified-id *only* to kick in as being maybe mutable agnostic. e.g., `decltype(id)` and `decltype(+id)` (where the unary + may be an overloaded operator that depends on the mutability of the `this` object).
> 
> (I'm not seeing the principle that guides this restriction proposed in the core issue yet, but those can be hashed out later.)
I do not think there is a general answer to "given these captures and this arbitrarily complex expression", would the mutability of the lambda affect the declaration of the parameters.
In this case we know it doesn't and that happen  to fix existing code, which make the solution tractable.
If core was keen to add any more complexity here, I think they should consider mandating a look-ahead of the `mutable` keyword even if that sounds rather complex. I don't think it will come to that, the proposed resolution will be good enough to reduce the blast radius of the paper, and I don't see a strong motivation to add even more complexity here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123909/new/

https://reviews.llvm.org/D123909