The winding road to PHP 8's match expression

New to the forthcoming PHP 8.0 release is a feature called match expressions, which is a construct designed to address several shortcomings in PHP's switch statement. While it took three separate request-for-comment (RFC) proposals in order to be accepted, the new expression eventually received broad support for inclusion.

The match expression story began at the end of March 2020 with an RFC suggesting changes to the switch statement. The proposal, authored by Ilija Tovilo and Michał Brzuchalski, highlighted four shortcomings of switch: the inability to return values from the statement, matches falling through to the next case, "inexhaustiveness", and type coercion.

The problem with switch

The PHP switch statement is one of the oldest constructs in the language, and shares a few common traits with the C variety; the proposal suggests that these common behaviors aren't ideal for PHP. For example, each case within a switch will fall through to the next case unless there is a break (or continue) statement. Also like C, switch is not an expression and therefore does not return any values. If a developer wants to, for example, assign a value from the logic of a switch construct to a variable, they need to do so explicitly as part of the corresponding case statement.

The RFC further suggests that the way switch handles types is incorrect for modern PHP. Since PHP is fundamentally a dynamically typed language, switch employs type coercion (called "type juggling" in the PHP manual). This means passing a string "0" into a PHP switch statement will match against an integer case 0: block, which might make less sense as PHP continues to embrace types in modern versions. Finally, the RFC points out that the switch statement is "inexhaustive", meaning that it is not an error if no case block was found to match.

The path to a solution

To address these concerns, the RFC proposed a new "expression variant" of switch:

    $result = switch($condition) {
        1 => foo(),
        2 => bar(),
        3, 4, 5 => baz(),
    };

This expression would operate in a similar fashion to the switch statement, however the evaluated code of a matched condition would be returned as an assignable value. The switch expression would also be more strict than its statement counterpart, eliminating fall-throughs and throwing an exception if a match was not found.

When Tovilo introduced the RFC (Brzuchalski did not participate in the discussion), it became clear that, as written, the proposal wasn't going to go far. In a limited discussion, Dan Ackroyd responded with several fundamental problems regarding the approach. While Ackroyd agreed there were issues with switch, he did not feel the RFC was a "good starting point" for that discussion. Ackroyd continued by itemizing his concerns and, since the RFC did not perform type coercion when comparing values, "it's way less interesting to me". In Ackroyd's view, he believed the new expression being proposed should employ a new keyword; which avoids the risk of potentially confusing developers by reusing switch.

The initial response to the RFC prompted Tovilo to conduct a poll to try to find the best way forward for the concept. When sharing the informal vote with the community, Tovilo explained the reasoning:

In response to the poll (and the justification for it), Rowan Tommins said "I think this confusion is there in your proposal, not just in people's responses to it", adding "I think changing the keyword to 'match', and possibly using strict comparison [not type coercion], would make a compelling feature."

In the end, the poll received five responses, not enough to build any consensus around the value of the proposal. The lack of appetite by the internals community for the RFC led Tovilo and Brzuchalski to withdraw it from consideration before a vote, replacing it the next day with a different proposal without Brzuchalski.

The new proposal introduced the match keyword, addressed type coercion, and fixed ambiguities in the original RFC structure to make the idea more clear; it yielded significantly more discussion than the original. Tommins seemed to appreciate the changes, yet still had several concerns. For example, Tovilo had suggested that the proposed match expression "allows you to use a match expression anywhere the switch statement would have been used previously." That was an idea Tommins took issue with:

Tovilo and Tommins, along with other community members, continued the debate of the proposal at length, mostly with regard to the statement blocks being added for match. Here is an example of a statement block from the proposal:

$y = match ($x) {
    0 => {
        foo();
        bar();
        baz(); // This value is returned
    },
}

PHP currently has no concept of statement blocks, and many community members found it strange to see them included as part of the proposed match expression syntax. Tommins, in particular, felt strongly that it was a mistake, though he liked the proposal otherwise; he expanded on this problem later in the thread, suggesting that statement blocks could be added in the future with more consideration. Another community member, Larry Garfield, supported Tommins in his suggestion to move statement blocks to a different proposal:

Tovilo declined to remove the proposed feature. Tommins also suggested separating the statement block issue into another vote within the RFC. Still, Tovilo didn't agree, saying:

When voting opened for the proposal in late April 2020, it was handily defeated in a 28 to 6 vote. A secondary vote within the RFC, "If you voted no, why?", indicated that one of the primary reasons that the proposal failed was the inclusion of statement blocks.

For a time, it appeared that was the end of the discussion regarding the match expression. However, in late May 2020, Tovilo returned with a third proposal for a match expression. This third RFC importantly did not include statement blocks and, unlike previous proposals, focused solely on the core features the match expression needed to have.

The policy on rejected RFCs within the PHP community states six months must pass between the rejection of a proposal and its re-submission. That is unless the "author(s) make substantial changes to the proposal." Tovilo argued that this applied, as "many people have said without blocks they'd vote yes". This argument was accepted without much challenge from the community, allowing the proposal to move forward.

The final proposal of the match statement addressed all of the fundamental concerns that Tovilo originally laid out, wrapped neatly into a new expression. match expressions are strictly typed when being compared, throw an exception if a match is not found, and the concept of "fall through" was eliminated. Perhaps unsurprisingly, this less expansive version of Tovilo's proposal was received positively; most comments and discussion from the community were about using => or : in the syntax. The RFC passed in a 43 to 2 vote in time for inclusion into PHP 8.0. Below is a representative example of how match expressions in PHP 8 are used:

    $foo = getSomeValue();

    try { 
        // this uses strict checking of types when looking
        // for a match (0 != "0").
        $result = match($foo) {
                404 => 'Page not found',
                Response::REDIRECT => 'Redirect',
                $client->getCode() => 'Client error',
            };
    } catch(UnhandledMatchError $ex) {
        print "Did not match!";
    }

While it took a few tries, the match expression looks to be a useful addition to language. More examples of the match expression in PHP 8.0 are available for interested readers; it is also available in the latest PHP 8.0beta2 release.