Skip to content

Self parameters & C-variadics should be syntactically legal in parenthesized generic argument lists #160797

Closed

Description

@fmease

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)

Footnotes

  1. They're however always semantically ill-formed as self is a module not a type. ↩

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Aug 9, 2026
  2. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    C-bugCategory: This is a bug.
    A-grammarArea: The grammar of Rust
    A-parserArea: The lexing & parsing of Rust source code to an AST
    T-langRelevant to the language team
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Aug 9, 2026
  3. fmease commented on Aug 9, 2026

    @fmease
    MemberAuthor

    RFC 3955 doesn't mention self parameters / C-variadics at all AFAICT. They did cross my mind when the RFC was still open but I didn't feel like discussing it given I was already submitting so many comments (arguably I should've though). However, when implementing this feature in my parser I thought about this topic again.

    I did label this with T-lang but their input isn't necessary until the stabilization of this feature. Of course, this change should be noted down in the tracking issue as a divergence from the RFC, so it doesn't get lost.

  4. fmease commented on Sep 11, 2026

    @fmease
    MemberAuthor

    #162634 will address the "self parameter" part.

  5. fmease commented on Oct 21, 2026

    @fmease
    MemberAuthor

    #164595 addressed attributes (not originally listed in the issue description).

  6. JonathanBrouwer commented on Oct 21, 2026

    @JonathanBrouwer
    Member

    Is there any part of this issue that is still open?

    This change should be noted down in the tracking issue as a divergence from the RFC, so it doesn't get lost.

    I'll do this

  7. fmease commented on Oct 21, 2026

    @fmease
    MemberAuthor

    Is there any part of this issue that is still open?

    Yas, C-variadics should probably be syntactically permitted (& semantically forbidden).

  8. JonathanBrouwer commented on Oct 22, 2026

    @JonathanBrouwer
    Member

    Right, I'll go fix that
    @rustbot claim

  9. fmease commented on Oct 22, 2026

    @fmease
    MemberAuthor

    r? me then over @ the PR :)

  10. added 3 commits that reference this issue on Oct 28, 2026
  11. added a commit that references this issue on Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

A-grammarArea: The grammar of RustA-parserArea: The lexing & parsing of Rust source code to an ASTC-bugCategory: This is a bug.F-named_fn_trait_parameters`#![feature(named_fn_trait_parameters)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language team

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions