1 Abstract

This paper argues, switch should be (re-)considered for Pattern Matching.

2 Background

Current Pattern Matching (PM) approaches (p1371¹ + discussion,² p2392³) steer away from basing the PM upon the switch, extending it. This is done for two reasons.

• Technical difficulties in determining if an expression is C-style switch or a PM.
• Teachability concerns, because of perceived differences b/w switch and PM.

The first issue is undoubtedly valid, but is not unsolvable and a solution will be presented in the next section.
The second issue is more interesting. This paper argues switch is already PM.
There are simply few restrictions to apply in order to make a switch:

• the only pattern allowed, alongside the wildcard pattern, is an expression with integer result;
  
• all patterns must be consteval;
  
• all patterns must be OR-ed together;

auto some_value = 2;

switch (some_value) {
  case 1:
  case 2:
  case 3: // execute the same code for all 3
}

auto some_value = 2;

inspect (some_value) {
 1 OR // (placeholder OR syntax)
 2 OR 
 3 => // execute the same code for all 3 
};

PM now acts as a switch, working only on compile time integer expressions and will continue matching until all patterns are checked.
…This is… as long there is one statement to execute. As we know, classic switch can execute multiple cases, even these not matched, because of fallthrough. In PM, assuming OR functionality, we can have multiple patterns evaluated, but they will have to lead to the same code. As shown, this is similar to fallthrough with empty cases, with added bonus of being explicit about it.

Considering fallthrough with non-empty cases is, if not a bad practice, a bad default, it turns out PM is simply more feature rich and safer switch.

The fact, switch is really just a very limited PM, is recognized by other languages and some of them use it directly for PM (Swift, C#, Java). What is more, all languages recognize switch and PM are not different features and no language has them both side by side! Either switch is used from the get go (Swift), or switch is evolved to handle more general patterns (C#, Java) or a different spelling is used (match, when, etc).

If C++ introduces a separate construct while keeping switch it will be the only one do so. This will hardly ease teachability. A better approach would be to have two levels of the existing switch, old and new, much like we have already with enum and enum class.

An argument can also be made, we intend to make PM an expression, not a statement like switch. In practice however, a switch-like PM will be returning void, making the difference b/w it a the old switch only the need to use a semicolon after it.

OK, say for a moment, we have both the old switch and a PM system, called “inspect”.
When we will teach to use switch? When we would say don’t use “inspect”? We can perform this kind of test with other control flow elements. For example, we can say, don’t use if-else chains, because and list few reasons. We can say, use for over while, because and we list again few good reasons.
Don’t use “inspect”, because…? And we really have no good reason, one we would teach. Sure, sometimes fallthrough with non-empty cases is “handy”, but would we teach it? No. We would teach to keep using “inspect” and present options to solve the needs in a more structured way, like using recursion for example. switch will never be “the better tool for the job” simply because “inspect” effectively subsume it for all cases that matter.
Now, one can argue, we have a similar precedent in the face of using replacing typedef. We introduced a new, more powerful tool, “that does the same”, under a completely different name, and left the old name alone.
Even if we ignore the inherent problem of introducing “one more way to do the same thing”, the situation here is not the same. using introduced a new way to do a declaration (variable-like, left to right assignment), one that would eventually, naturally support template arguments. Achieving the same, reusing typedef would have been forced and contrived, even if possible syntactically. It is not the case here, we don’t need new form of anything. As you can see from the example above, both forms are almost identical, with further similarities explored in this paper. It is not like for example switch, compared to if-else chain, where the difference in form is considerable (arbitrary number of queried items in a chain, vs one queried item in a tree).

We could have both side by side, but we don’t have to. Especially, considering the painful process we’ll have to come through when introducing a keyword with as popular spelling as “inspect” or “match”, that also can’t be context aware my definition.

3 Proposal

In the previous section we mentioned the parsing challenge of differentiating b/w regular switch and one that does PM, if we opt to reuse the introducer keyword.
This issue can be resolved by altering the syntax slightly and instead of using round parenthesis, we use square ones:

switch (a)      //< old C-switch for `a`
...
switch [a]      //< pattern match for `a`
...
switch [a, b]   //< pattern match for both `a` and `b`

With square brackets after switch, a PM expression is introduced, instead of a C-style switch statement.

This way we not only can continue to use the already reserved keyword, but also have a safe-by-default switch, one that does not fallthrough:

auto some_value = 2;

switch (some_value) {
  case 1:   
    ... 
    break;
  case 2:   
    ... 
    // missed break
  case 3: 
    ... 
    break;
  ...
}

auto some_value = 2;

switch [some_value] {
  case 1:   
    ... 
    break;
  case 2:   
    ... 
    // missed break, but no fallthrough
  case 3: 
    ... 
    break;
  ...
};

The only textual difference between these two are the brackets after switch and a semicolon at the end.

All functionality of switch remains the same, with the exception of fallthrough, in particular default, break, return and continue work exactly the same as they do currently.

Because this is now PM, many new patterns are available. For example we can match strings:

auto some_value = string("hi");

switch [some_value] {
  case "hi":   // handle "hi"
  case "bye":  // handle "bye" 
  default:     // handle all else
};

Or use advanced patterns:

auto some_value = Point(12, 13);

switch [some_value] {
  case [0, 0]: // handle point at origin 
  case [0, _]: // handle x at origin 
  case [_, 0]: // handle y at origin 
  ...
};

In other words, switch becomes full-featured PM, with barely any new syntax.
If we want the expression to have a result, we use a different case syntax and optionally a return type, as per current main proposal (p1371):

auto some_value = true;

auto result = switch [some_value] {
  true => "yes";
  false => "no";
};

auto some_value = true;

auto result = switch [some_value] -> std::string {
  true => "yes";
  false => "no";
};

Lastly, we can mix both case types.
We use case: and default, when we want a statement.
We use => and __, when we want a result-producing expression:

enum class Op { Add, Sub, Mul, Div };
Op parseOp(Parser& parser) {
  return inspect (parser.consumeToken()) {
    '+' => Op::Add;
    '-' => Op::Sub;
    '*' => Op::Mul;
    '/' => Op::Div;
    let token => !{
      std::cerr << "Unexpected: " << token;
      std::terminate();
    }
  };
}

enum class Op { Add, Sub, Mul, Div };
Op parseOp(Parser& parser) {
  return switch [parser.consumeToken()] {
    '+' => Op::Add;
    '-' => Op::Sub;
    '*' => Op::Mul;
    '/' => Op::Div;
    case [[noreturn]] let token: {
      std::cerr << "Unexpected: " << token;
      std::terminate();
    }
  };
}

This paper leaves many details out as they are already handled by P1371.

As you can see, evolving switch to handle PM is not only possible, but ultimately natural and beneficial, improving both the existing switch uses (safer, reacher) and the PM development as we can reuse its building blocks like introducer keyword, statement cases, etc.
Evolving switch also keeps the language smaller. There is less new syntax, less new ways of doing the same thing (!) and ultimately less new to learn for a newcomer.

If we have both PM and switch, which one should be thought first? Probably PM, the modern system. And this will have to be with something simple, so simple that will resemble switch. But at some point, one will have to learn switch as well, repeating the same process twice, once using the new form, once using the older, combined with a lesson why and how these two are different. The more those two overlap, the less learning to be done.

auto p = Point(12, 13);

if(case [_, let x] && [0,0] = p) { //< (using the Kona 2022 suggested syntax for the pattern)
  // get x iff point is at origin
}

auto p = Point(12, 13);
auto o = Point(0, 0);

if(case o = p) {
  // point is at origin, same as o == p
}

if(switch [p] [_, let x] && [0,0]) { //< (using the Kona 2022 suggested syntax for the patterns)
  // get x iff point is at origin
}

auto r = Rect(12, 13, 100, 200);

case [let p, let [_, h]] = r;

auto p = Point(12, 13);
int x, y;

case [&x, &y] = p;