Self parameters shouldn't be syntactically forbidden in this position (only semantically) since that diverges from every other place that can contain "function parameters" IINM.
We intentionally allow self parameters in e.g., function pointer types (CC #68764, rust-lang/reference#2240 (comment)) and free function items. As it stands, it means we reject X(self), X(&self), X(&mut self) but accept X(&&self), X(&&mut self) for example (the latter are rightfully legal as they're interpreted as X(_: &&self) & X(_: &&mut self) essentially1).
Similarly, for C-variadics. They should be syntactically allowed, too, IMO.
Unifying this would once again simplify the grammar; we shouldn't fight the fact that self parameters & C-variadics are (meant to be) syntactically valid fn params always.
Originally posted by @fmease in #158517 (comment)
Self parameters shouldn't be syntactically forbidden in this position (only semantically) since that diverges from every other place that can contain "function parameters" IINM.
We intentionally allow self parameters in e.g., function pointer types (CC #68764, rust-lang/reference#2240 (comment)) and free function items. As it stands, it means we reject
X(self),X(&self),X(&mut self)but acceptX(&&self),X(&&mut self)for example (the latter are rightfully legal as they're interpreted asX(_: &&self)&X(_: &&mut self)essentially1).Similarly, for C-variadics. They should be syntactically allowed, too, IMO.
Unifying this would once again simplify the grammar; we shouldn't fight the fact that self parameters & C-variadics are (meant to be) syntactically valid fn params always.
Originally posted by @fmease in #158517 (comment)
Footnotes
They're however always semantically ill-formed as
selfis a module not a type. ↩