[RFC][Draft] Match block

Hello everyone

I've been working on match blocks over the last few weeks.
https://wiki.php.net/rfc/match_blocks

Hi Ilija,

Thanks for working on this. A few initial thoughts...

The use of "<-" as the new token doesn't fit the language very well. The "family" it belongs to are all keywords not symbols: return, yield, throw, break, continue. I understand that you don't want to reuse one of those, but presume a new keyword would not need to be fully reserved?

Relatedly, I note that in the RFC text, you've talked about the arms "returning" a value, but also made clear that a return statement is also allowed. I think it would be clearer to pick a term other than "return" for what this token does, and use it consistently.

My suggestion to start the ball rolling is "resolve" - that is, "The block resolves to a value given after the 'resolve' keyword."

Having said all that, the ability to put control flow like return and yield into match statements feels a little weird to me. Again, it's partly the syntax - the "=>" is reminiscent of array literals and short lambdas, which are very much expressions not statements.

You say in the introduction that part of the motivation is to more completely replace "switch", but I wonder if that would be better solved with a different construct that handles the non-expression-like uses of switch. In particular, although fall-through by default (if "break" is not specified) is definitely a historic mistake, the ability to fall through to another case is sometimes useful, so those cases would still not be convertible to "match".

A "strict switch" could look more like the current control flow structures, but add strict equality (and pattern matching in future) and remove implicit fall-through, without having to squeeze into the same syntax as match expressions.

My final thought for now is a short and slightly off-topic one: someone really needs to look into adding opt-in block scoping to PHP, similar to JS "let". It would fit so well with proposals like this one!

Regards,

--
Rowan Tommins
[IMSoP]

Hello everyone

I've been working on match blocks over the last few weeks.
https://wiki.php.net/rfc/match_blocks

I've already shared it in R11 and got conflicting feedback, which
makes me unsure on how to proceed. We have a few options.

1. Add blocks only to match, possibly adding blocks to other
   constructs in separate RFCs (the approach of this RFC)
2. Support block expressions as a language-level concept, analogous to
   https://doc.rust-lang.org/reference/expressions/block-expr.html
3. Do nothing

The two main complaints/questions I've gotten was whether this
approach is the right one, and whether the syntax can be improved. The
RFC tries to go into detail on explaining the rationale for the chosen
approach. Additionally, it proposes a few alternate syntax options,
although none of them are very satisfactory.

At this point I'm unsure whether a proposal can satisfy all camps. Let
me know if you have any thoughts/ideas.

Ilija

--

To unsubscribe, visit: https://www.php.net/unsub.php

Hi Ilija,

This seems like an interesting subject for the PHP language, but
unfortunately doesn't take the direction I would much have preferred. The
use of <- to denote a different style of return statement in a block
feels quite "alien" (for lack of a better word) in the language for me. In
addition to that, I'm also not sure if there's anything else in PHP that
behaves differently when a return value is expected or not - this is in
relation to the difference between $result = match() vs match() without
expecting a result. If there's anything else in PHP that already has a
similar behavior, it might be worth adding it to the RFC so that we can
relate the subjects.

To me it would be much better to stick with the existing language
constructs just as-is.

<?php

var_dump(match ('foo') {
    'foo' => {
        echo "foo branch reached\n";
    },
});
// foo branch reached
// `NULL` 

var_dump(match ('foo') {
    'foo' => {
        echo "foo branch reached\n";

        return 'this will be dumped';
    },
});
// foo branch reached
// string(19) "this will be dumped

var_dump(fn () => {
    echo "auto-capturing short closure invoked\n";
}());
// auto-capturing short closure invoked
// `NULL` 

var_dump(fn () => {
    return 'foo';
}());
// string(3) "foo"

$foo ??= {
    bar();
};
var_dump($foo);
// `NULL` 

$foo ??= {
    bar();

    return 'baz';
};
var_dump($foo);
// string(3) "baz"

There's a somewhat related discussion on this RFC
https://wiki.php.net/rfc/auto-capture-closure#multi-line_expressions which
comes to mind and was just 2 votes short of have been approved.
Other good-related RFCs are https://wiki.php.net/rfc/short-match and
https://wiki.php.net/rfc/short-functions which creates a really nice
symmetry in the language syntax.

Ultimately, this is a sad 10-year-long discussion (as summarised here:
https://externals.io/message/113740#113833) that seems impossible to move
forward within the PHP language. The door of creating of a block with
auto-capture look-and-feel much better across many different aspects of the
language, but it's always shutdown by enough long-time voters.

Overall, between the choice of creating a new syntax that "kind of
represents return statements on specific scenarios" or option 3 - do
nothing, I would prefer to do nothing until we manage to gather enough
voters to overcome the "no-auto-capture" camp.

--
Marco Deleu

Hello everyone

I've been working on match blocks over the last few weeks.
https://wiki.php.net/rfc/match_blocks

I've already shared it in R11 and got conflicting feedback, which
makes me unsure on how to proceed. We have a few options.

1. Add blocks only to match, possibly adding blocks to other
   constructs in separate RFCs (the approach of this RFC)
2. Support block expressions as a language-level concept, analogous to
   https://doc.rust-lang.org/reference/expressions/block-expr.html
3. Do nothing

The two main complaints/questions I've gotten was whether this
approach is the right one, and whether the syntax can be improved. The
RFC tries to go into detail on explaining the rationale for the chosen
approach. Additionally, it proposes a few alternate syntax options,
although none of them are very satisfactory.

At this point I'm unsure whether a proposal can satisfy all camps. Let
me know if you have any thoughts/ideas.

Ilija

As we've discussed elsewhere, I favor option 2: Language level concept. I cannot speak to the implementation details, but let me offer two specific bits of justification.

1. The RFC says "For match, whether the block should require returning a value depends on whether the match itself returns a value." - I disagree. Returning a value should always be legal; if the value isn't assigned to a variable it is lost, but oh well, that's how PHP already works. Moreover, if the argument is rather "if match's result is saved, then each branch must return a value", well, the same is true for use in many other cases, such as with the null short-hands.

2. Speaking of, this is a pattern I find myself writing all the time:

class Foo {
private array $things;

public function getThing(string $id): ?Thing {
$this->things ??= $this->makeThingTable();
return $this->things[$id] ?? null;
}

private function makeThingTable(): array {
// Something complex here.
}
}

Allowing multi-line expressions on ??= would allow that to be collapsed to a single function, without the need to come up with a name for makeThingTable(), or splitting logic between two methods, etc. I believe that is a valid and useful use case for multi-line expressions outside of match() that can/should be supported. (One could argue that it's possible to just use a self-executing closure, which is true, but is also verbose and ugly and requires manual capture. That same option is also available for match arms today, with the same problem, which is why we're looking for a better solution.)

class Foo {
private array $things;

public function getThing(string $id): ?Thing {
$this->things ??= {
// Something complex here.
};
return $this->things[$id] ?? null;
}
}

I am flexible on the syntax used. I agree that a keyword would be more PHP-ish than <-, but I wouldn't start a riot either way. If just { } makes the parsing hard, I have in the past suggested {{ }} to denote a multi-line expression, which should be sufficiently parser-unique.

We could settle for a solution that works for all cases, returning null by default. Whether this solution is acceptable is likely a matter of taste.

That would taste just fine to me, frankly, and I'm OK with the code block shown right after it.

--Larry Garfield

2. Support block expressions as a language-level concept, analogous to
   https://doc.rust-lang.org/reference/expressions/block-expr.html

This is my personal preference. As I mentioned in chat, if we go this
route, there is a notable pain point: in "short" closures which have
blocks, how do you capture by reference if needed?

Consider this situation:

// function array_push(array &$array, mixed ...$values): int;
$array = [];
$value = fn ($x) => array_push($array, $x);

I have an incomplete idea about allowing & at the call-site if and
only if the corresponding parameter is taken by reference:

// Ok, $array is taken by reference in array_push
$value = fn ($x) => array_push(&$array, $x);

// Not ok, ...$values are not taken by reference in array_push
$key = '';
$value = fn ($x) => array_push(&$array, &$key, $x);

Then, when & is given at the call-site, that variable is captured by
reference. If they don't want it to be captured by-reference, then
they have choices:

// Choice 1: omit the `&` at the call-site.
$value = fn ($x) => array_push($array, $x);

// Choice 2: copy the array.
// Assumes blocks are allowed.
$value = fn ($x) => {
    $copied = $array;
    array_push(&$copied, $x);
}

It would still be valid to omit & at the call-site in PHP 8.x so a
transition can be made. Theoretically, we could make it required in
PHP 9.0 or 10.0.

Nikita started an RFC for this 5 years ago:
https://externals.io/message/101254

I do not know exactly why it was not voted on. There was substantial
drama in the discussion that was, in my opinion at least, not really
relevant to the RFC contents.

The original motivations still stand:

1. The code becomes more readable by humans.
2. The code becomes more readable by analyzers and optimizers.

And now we have another reason:
3. Enables auto-capture by-reference when it is necessary.