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

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Apr 18 05:48:40 PDT 2022

aaron.ballman added inline comments.

Comment at: clang/lib/Parse/ParseExprCXX.cpp:700
+  if (Tok.is(tok::identifier) && NextToken().is(tok::r_paren)) {
+    SourceLocation TemplateKWLoc;
cor3ntin wrote:
> 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.
Eh, I'm less convinced. The changes in P2036R3 were a band-aid to fix mistakes. The core issue "fixing" it is another band-aid over the top of P2036R3. My experience is that band-aids over band-aids rarely leads to a good feature that users can make sense of. The fact that I can't make heads or tails of what the actual language design rule is here also means this is painful for us supporting our own extensions (like `alignof` on an object instead of a type, `__typeof__` instead of `decltype`, etc).

Personally, I'd prefer the core issue was resolved in a more clean fashion than carving out a few exceptions under the hope that it's "good enough". However, that's something for us to fight about in Core when this comes up. For the moment, I'm happy enough with this because it gets libstdc++ unstuck.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list