rust-lang / rust-lang/rust

Tracking Issue for Never Patterns (`never_patterns`)

Open
#118,155 42 comments 13 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-exhaustiveness-checking B-experimental B-unstable C-tracking-issue F-never_patterns S-tracking-impl-incomplete T-lang
Dominant language
Rust
Stars
119k
Forks
16.1k
PR metrics pending

Description

View all comments

This is a tracking issue for the experimental "never patterns" feature (as per the T-lang experimental feature process).
The feature gate for the issue is #![feature(never_patterns)].

RFC: https://github.com/rust-lang/rfcs/pull/3719

This feature introduces a new syntax for patterns: !. In a pattern, ! is valid for any uninhabited type and simply acknowledges that the type is empty. Because a never pattern is statically known to be unreachable, it obeys slightly different rules:

enum Void {}
let result: *const Result<u32, Void> = ...;
unsafe {
    match *result {
        Ok(x) => { foo(x) }
        Err(!), // no need for `=> <expr>`
    }
    let (Ok(x) | Err(!)) = *result; // valid
}

fn blah(!: Void) -> SomeType {} // the function can never be called so it doesn't need a body

This feature does not affect exhaustiveness or pattern reachability; see the exhaustive_patterns and min_exhaustive_patterns features for that.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps
Unresolved Questions
Implementation plans/details
  • ! is parsed as a pattern.
  • Parsing of match expressions allows match <expr> { <pat>, ... } i.e. a pattern without a body. We later check to only allow that if the pattern is a never pattern.
  • The lack of body is desugared into something equivalent to unreachable_unchecked!().
  • Never patterns skip the or-pattern bindings check, to allow Ok(x) | Err(!)
  • Never patterns don't allow bindings, like in (x, !)
  • Allow fn foo(!: Void) -> SomeType {}
  • ! is typechecked like a wildcard; it adds no type constraint
  • In match checking we check that ! is only used on an uninhabited type (modulo match ergonomics).
  • The ! pattern is lowered to MIR.
  • A ! pattern asserts validiy of the matched place
  • Exhaustiveness understands !.
  • Exhaustiveness recommends using never patterns where sensible.
  • Rustfmt understands never patterns
  • Check every bit of the compiler that handles or-patterns to see if it handles never patterns properly
  • Write up the RFC
  • https://github.com/rust-lang/rust/issues/120240
Implementation history

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the RFC and the unchecked implementation items, especially MIR lowering, validity checking, rustfmt support, and handling of or-patterns. Review the referenced implementation history and the rustc-dev-guide stabilization and documentation guidance. Done means the remaining checklist items are addressed and the unresolved questions have been resolved.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.