[PATCH] D140828: [C++] Implement "Deducing this" (P0847R7)

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/test/SemaCXX/cxx2b-deducing-this.cpp:192
+        f();       // expected-error{{call to non-static member function without an object argument}}
+        f(Over_Call_Func_Example{});   // expected-error{{call to non-static member function without an object argument}}
+        Over_Call_Func_Example{}.f();   // ok
----------------
aaron.ballman wrote:
> cor3ntin wrote:
> > aaron.ballman wrote:
> > > cor3ntin wrote:
> > > > aaron.ballman wrote:
> > > > > Errr, this diagnostic seems likely to be hard for users to act on: this non-static member function has an object argument! And it's even the right type!
> > > > > 
> > > > > If the model for the feature is "these are just static functions with funky lookup rules", I kind of wonder if this should be accepted instead of rejected. But if it needs to be rejected, I think we should have a better diagnostic, perhaps along the lines of "a call to an explicit object member function cannot specify the explicit object argument" with a fix-it to remove that argument. WDYT?
> > > > UGH, phab is confused, I'm no longer sure which diag you are concerned about...
> > > ```
> > >     static void h() {
> > >         f();       // expected-error{{call to non-static member function without an object argument}}
> > >         f(Over_Call_Func_Example{});   // expected-error{{call to non-static member function without an object argument}}
> > >         Over_Call_Func_Example{}.f();   // ok
> > >     }
> > > ```
> > > from around line 214 in the latest patch; the second error seems hard to understand because there is an object argument being passed, it's just not the form allowed.
> > You have a rewording suggestion?
> How about we split it into two diagnostics:
> ```
> static void h() {
>   f(); // expected-error{{call to non-static member function without an object argument}}
>   f(Over_Call_Func_Example{});   // expected-error{{cannot pass an explicit object as an argument to the call; did you mean to use '.'?}}
>   Over_Call_Func_Example{}.f(); // ok
> }
> ```
> the idea being: if the call is to an explicit object function and the user provided an extra argument to the call whose type and position matches the explicit object parameter, we tell the users "that's now how you use this" and best-case give them a fix-it to move the argument to before the call and add a `.`?
@cor3ntin and I discussed this suggestion off-list and came to the conclusion that it would be ideal to improve the error here (and perhaps have a note that points to the `this` in the declaration of `f()` + a fixit) but it would be difficult to come up with a heuristic for in all cases. Consider a declaration like `void f(this auto, Over_Call_Func_Example);` which is called with `f(Over_Call_Func_Example{});` from within a static function as a corollary test case to the above.

Let's punt on this for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140828