Discussion: goto case statements and pattern-matching

[alrz]

Currently, pattern matching made goto case statements useless, but there exist some valid use cases, and even more with the recent additions.

A simple example is when you use case var p: instead of default: and you no longer can use goto default;.

switch (M()) {
    case 1:
        goto default; // nope
    case var p: // must capture `M()` in a local if `default:` is used.
        Use(p);
        break;
}

Relational patterns are interesting in that it's likely that all the consecutive patterns could overlap with each other.

switch (M()) {
    case > 1000:
        break;
    case > 100: // this is statically valid if the previous case is evaluated.
                // if you want this section to run, you have to rewrite the whole thing with `if` statements
        break;
}

As for the most common use cases, we could use fallthrough to transfer the control to the very next section.

switch (M()) {
   case 1:
       fallthrough;
   case var p: // p is definitely assigned, because `var p` subsumes `1`
       Use(p);
       break;
}

If the subsequent pattern would not subsume the current one, pattern variables (if any) are not definitely assigned -- not so if otherwise.

switch (M()) {
    case int i:
        fallthrough;
    case IComparable p: // p is definitely assigned, because `IComparable p` subsumes `int i`
        Use(p); // ok
        break;
}

switch (M()) {
    case int i:
        fallthrough;
    case double d:
        Use(d); // error
        break;
}

Note that if the next pattern has a when clause, it will NOT be evaluated.

This is the same as Swift's fallthrough -- we are merely transferring control and not evaluating case labels.

If we do want to evaluate when clauses, we will need to use another keyword: resume which will also evaluate case labels.

switch (person) {
    case { }:
        // fallthrough;
        // resume;
    case Student:
        break; // `fallthrough` in the previous section always transfers here
    case Teacher:
        break; // `resume` either transfers here or the case above, 
               // depending on the runtime type of `person`
}

To jump to an arbitrary case label we could use the old goto case generalized to accept a pattern: goto case <pattern>

switch (person) {
    case { }:
        goto case Teacher;
    case Student:
        goto case _; // jumps to the last section because `var p` subsumes `_`
    case Teacher p: // not definitely assigned because `Teacher p` does not subsume `{ }`
        break;
    case var p: // definitely assigned because `var p` subsumes `Student`
        break;
}

There must exist a case label that subsumes the <pattern> in goto case, otherwise a compile-time error is produced. Variable def-assignment rules still applies depending on the current pattern, but no variables are permitted in goto case itself.

With the above, fallthrough; would be a shorthand for goto case <very next pattern> with the exception that when clauses are permitted but not evaluated. This rule is driven from the current goto case which is not permitted in presence of a when clause.

We could also consider next; as a shorthand for goto case <first subsuming pattern> which will resolve to goto case _; most of the time, unless there exists a more specific pattern that could be picked. In this situation, it's likely that we could use resume instead, except that no when clause is evaluated and the target is always known at the compile-time.

[ghord]

Another idea would be to accept arbitrary expression in goto case ... and pattern match on this new expression again from the start.
This way we could write:

switch (M()) {
    case > 1000:
        goto case 999;
    case > 100: 
        break;
}

I think this would be compatible with old goto case ... and is very simple to explain to people learning pattern matching

[jnm2]

s/subsum/subsume (×6)

It seems like there should be an equivalence between fallthrough and top-level or pattern chaining.

[alrz]

@ghord

Another idea would be to accept arbitrary expression in goto case

I think that was originally proposed by @gafter in C# 7.0 timeframe but cutted out. I believe accepting a pattern could make this more "predictable", rather than an arbitrary expression. The motivation here is to jump to a specific case label, not reevaluate the switch against a brand new expression. Besides, it would be hard to specify some case labels like case var x with an expression. Also, you don't want to lose the original value. goto case expression completely overrides that which is likely not what you want.

[alrz]

@jnm2 Fixed. Thanks!