Skip to content

Allow evaluation and pattern matching within guards (what Haskell calls "pattern guards") #12830

Closed

Description

@kmcallister

What Rust calls "pattern guards" are just called "guards" in Haskell. Pattern guards in Haskell allow additional evaluation and a refutable pattern match. If that pattern match fails, it's as if a regular guard returned false. Here's an example, adapted from the HTML5 tokenizer I'm working on.

fn process_char(&mut self, chars: CharSource) {
    match self.state {
        TagOpen => match chars.next() {
            '/' => { self.state = EndTagOpen; }
            c if (Some(a) <= c.to_ascii_opt()) => { do_something(a.to_lower()); }
            c if other_condition => { ... }
            _ => parse_error()

(I'm not advocating for this particular concrete syntax, just trying to get the idea across.)

One can always refactor to avoid the fancy guard, but in general it can produce ugly, hard-to-follow trees of nested matches. In this case I would love to have a single match per tokenizer state which closely follows the specification.

Pattern guards have proven tremendously useful in GHC and were one of the few GHC extensions accepted into Haskell 2010. I think Rust could benefit just as much.

Activity

  1. Aatch commented on Mar 11, 2014

    @Aatch
    Contributor

    Hmm, while not ideal, this does work today:

    let a;
    let b = Some(1);
    match b {
      Some(c) if {
        a = c+1;
        a == 2
      } => println!("{}", a),
      Some(_) => println!("Some"),
      None => println!("None")
    }

    Prints 2;

  2. kmcallister commented on May 23, 2014

    @kmcallister
    ContributorAuthor

    I started using something like that in another part of the library. In this style, the example above would become

    match chars.next() {
        '/' => { self.state = EndTagOpen; }
        c if match c.to_ascii_opt() {
            Some(a) => { do_something(a.to_lower()); true }
            _ => false,
        } => (),
        c if other_condition => { ... }
        _ => parse_error()
    

    Which is sort of weird, but easy enough to get used to.

  3. steveklabnik commented on Jan 21, 2015

    @steveklabnik
    Contributor

    I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

    This issue has been moved to the RFCs repo: rust-lang/rfcs#680

  4. added a commit that references this issue on Aug 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: An issue proposing an enhancement or a PR with one.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions