Repository navigation
[expr.prim.lambda.closure] Conversion to function pointer doesn't account for explicit object parameter CWG2561 #5294
Description
Activity
IIUC the explicit object parameter could be used in the lambda-expression. E. g.
struct C { C(auto); void f(); }; auto lambda = [](this C c) { c.f(); }; // OK?
IIUC if the conversion function excludes the explicit object parameter, then the above
lambdawould be convertible tovoid(*)(), and the resulting function pointer would point to a function that callsc.f()for some nonexistentc. I don't think this makes sense.Reacted by Barry RevzinSounds like non-editorial CWG issue material to me.
Sounds like non-editorial CWG issue material to me.
Yeah, definitely. I just wasn't sure if you preferred me emailing Core or posting it here.
And per @cpplearner's comment, the wording may not even be wrong 😄.
Yeah, with some more thought,
[](this C c) { c.f(); }has to be avoid(*)(C), which I think means that the wording is correct.But I think we still need to change
The value returned by this conversion function is the address of a function F that, when invoked, has the same effect as invoking the closure type's function call operator on a default-constructed instance of the closure type
as it's not clear what that would mean, e.g.
struct C { C(auto) { } }; void foo() { auto l = [](this C) { return 1; }; int (*fp)(C) = l; // EDIT: originally incorrectly had void as return type fp(1); // same effect as decltype(l){}() or decltype(l){}(1) ? }(
fpshould instead just be the address of the function call operator?)Why is
fpa pointer to function returningvoidwhen the lambda returnsint?Reacted by Christof Meerwald- changed the title
[-][expr.prim.lambda.closure] Conversion to function pointer doesn't account for explicit object parameter[/-][+][expr.prim.lambda.closure] Conversion to function pointer doesn't account for explicit object parameter CWG2561[/+]on Apr 2, 2022 Ack, thanks!
Paragraphs 8 and 9 talk about what kind of function pointer a capture-less lambda is convertible to:
and
Those aren't quite right in the case of an explicit object parameter. Since this should probably work:
For the non-generic case, something like this:
Though wording this for the generic case is trickier since we need to skip the invented template parameter of the explicit object parameter, which might hypothetically also be used by some other parameter?