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 lambda would be convertible to void(*)(), and the resulting function pointer would point to a function that calls c.f() for some nonexistent c. I don't think this makes sense.

Sounds 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 a void(*)(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) ?
}

(fp should instead just be the address of the function call operator?)

Why is fp a pointer to function returning void when the lambda returns int?

CWG2561