Skip to content

Bodiless match arms not being unconditionally syntactically legal is surprising and unprincipled #153134

@fmease

Description

@fmease

AFAICT the open RFC 3719 doesn't specify if bodiless match arms are unconditionally legal or not (A never pattern is accepted as an arm in a match expression, and that arm takes no body nor guards. doesn't tell us that esp. since that sentence talks about the semantics, not the syntax). I'm opening this discussion here instead of over there because this concerns rustc's current behavior I'm strongly disagreeing with and which I consider to be a blocker for never_patterns (I know that bodiless arms in general are contested & might not make it into the final version of the RFC).

Currently rustc only syntactically accepts a bodiless match arm (i.e., one that "doesn't end in => $expr") under feature never_patterns if

  1. the pattern "might contain a never pattern" (i.e., the pattern syntactically contains a never pattern or it's a macro call (!)) or
  2. it's "the last arm of the match expr" (i.e., if the pattern is followed by } instead of e.g., ,) or
  3. it has a guard (i.e., if the pattern is followed by if).

I find this partly rule partly heuristic incredibly complex and unprincipled. I would just make all bodiless match syntactically legal. I know that we currently have a nice parser diagnostic + recovery for match $expr { $pat, $pat, … … }match $expr { $pat | $pat | … … } (i.e., helping users who confused , with |). That would indeed no longer be possible. Still, we can provide a similar structured suggestion in a later, semantic analysis pass.

Concretely, it means we currently syntactically accept match(){ x }, reject match(){ x, }, accept match(){ x if(), }, reject match(){ X(), Y() => {} }, accept match(){ X!(), Y!() => {} }.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-grammarArea: The grammar of RustA-parserArea: The lexing & parsing of Rust source code to an ASTA-patternsRelating to patterns and pattern matchingC-discussionCategory: Discussion or questions that doesn't represent real issues.F-never_patterns`#![feature(never_patterns)]`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