https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #19 from Gašper Ažman <gasper.azman at gmail dot com> --- Correct, the use of the capture is the source of the error, not the instantiation with an unrelated type. On Sat, Sep 2, 2023, 09:54 waffl3x at protonmail dot com < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609 > > --- Comment #18 from waffl3x <waffl3x at protonmail dot com> --- > (In reply to Gašper Ažman from comment #17) > > Read through the patch quickly, want to suggest a few tests. > > > > When a lambda has captures, the explicit object parameter is used to get > at > > them *silently*, if they are related, otherwise the program is > ill-formed: > > > > int x = 42; > > auto f1 = [x](this auto&&) { > > return x; > > }; > > auto f2 = [](this auto&&) { return 42; } > > > > static_cast<int(*)(decltype(f1)&)>(decltype(f1)::operator()); // OK > > static_cast<int(*)(int&)>(decltype(f1)::operator()); // ERROR > > static_cast<int(*)(int&)>(decltype(f2)::operator()); // OK > > Ah I see, thanks for the input. I was actually wondering about that, > especially > if you were expected to use the explicit object parameter to access > captures. > Is my understanding correct that the second case would not be an error if > captures were not used in the body of the lambda? Based on your wording I > would > believe that is the case, so implementing this behavior would not be as > simple > as just disallowing unrelated deduced types when there are captures. > > Unfortunately, I will not have access to my computer for a while more, I > plan > on setting up an environment at another computer and fixing the formatting > errors that were noted, but I will wait until I have access to my computer > before I work on it more seriously I think. > > Thanks a lot for looking at the patch though, I really appreciate the time > you've taken. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
