The Fall-Through Proposal

language design
1

If you're trying to optimize an enum's size it can be nice to use different variants instead of booleans. But it comes with a tradeoff: code reuse.

So you have this large enum with things like StringKey and NonValidatingStringKey and you have to copy-paste the code for StringKey into the NonValidatingStringKey match case because they do slightly different things, e.g.

match foo {
  StringKey(x) => {
    //code here
    return option.map(Some).ok_or_else(|| ValidationError(etc, etc))
  },
  NonValidatingStringKey(x) => {
    //pretty much exact same code here
    return Ok(option)
  }
}

It'd be nice if you could do something like this:

match foo {
  StringKey(x) as let skip=false | NonValidatingStringKey(x) as let skip=true => {
    //code here
    if skip {
      return Ok(option)
    } else {
      return option.map(Some).ok_or_else(|| ValidationError(etc, etc))
    }
  }
}

So you get all of the benefits of fallthrough (aka code reuse) with none of the drawbacks (because it's not fallthrough).

2

You can do

let (skip, x) = match foo {
    StringKey(x) => (false, x),
    NonValidatingStringKey(x) => (true, x),
}
// code here
3 Likes
3

I believe that if let guards are planned, but they always apply to the entire match arm. This restriction could be removed by requiring parentheses in some cases:

match foo {
    A | B if bar => {}
    // is equivalent to
    (A | B) if bar => {}

    // This could be allowed too:
    (A if bar) | (B if !bar) => {}
    (A if let x = true) | (B if let x = false) => {}
}
4

For these examples, yes. Now try it with this:

pub(crate) enum PatternElement<T: PatternTypes> {
    Arrow,

    Identifier(usize),

    StringKey(usize),
    RegexKey(usize),
    KeySubtree(usize),
    ValueSubtree(usize),
    Paramemter(usize),
    ApplyPredicate(usize),

    SkipStringKey(usize),
    SkipRegexKey(usize),
    SkipKeySubtree(usize),
    SkipValueSubtree(usize),
    SkipParamemter(usize),
    SkipApplyPredicate(usize),

    End
}
5

I don't follow. What is it that you're trying to achieve, and why is current syntax not good enough?

6 
match pattern_element {
    case StringKey(key) | SkipStringKey(key) {
        let skip = matches!(pattern_element, SkipStringKey(_));
        // ...
    }
    // etc
}
7

Yeah, that's what we're currently using. We believe it has some issues that need to be acknowledged tho, like accidentally using different pattern_elements in the match and in the matches!.

8

You could also refactor (or have a translated type) such that you have something like:

struct Whatever {
  skip: bool,
  whatever: EnumWithoutTheAlmostDuplicateVariants,
}

You could also refactor (or have a translated enum) so that your variants look more like:

pub(crate) enum PatternElement<T: PatternTypes> {
  StringKey(usize, bool),
  // No SkipStringKey
}

This one is particular is basically @CAD97's suggestion, factored out into a translation method (From impl maybe) so that there's only one place to make those mistakes.

9

A key important thing to note here is that this doesn't have to be the version of the enum that you store and pass around. It can be a transient form that you just create temporarily to make it easier to work with.

1 Like
10

Hmm...

We still gain the memory usage savings when doing that?

Also: What do we lose from not having a replacement for fall-through? Rust has enums, as a replacement for tagged unions. Rust uh wait did we ever merge/stabilize label-break-value? as an alternative to goto. Having something that's more restrictive than fall-through, but still enables some common fall-through-related ergonomics, would be nice.

11

You could solve that by creating an fn is_skip(&self) -> bool method and just calling it before (or after) you match. You can always mis-write code. The normal solution to that kind of thing is to separate concerns behind different abstractions.

12

Separating concerns behind different abstractions is the problem tho. By keeping things together, you reduce risk of mistakes.

(Foo if let x=true) | (Bar if let x=false) would be nice.

1 Like
13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.