On Sat, Apr 11, 2020, at 7:16 PM, Ilija Tovilo wrote:
> Hi internals
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>
> Due to the feedback I decided to take the RFC in a slightly different
> direction. The main objections were:
>
> 1. It didn't behave like the traditional switch so it shouldn't use
> the switch keyword
> 2. It didn't fix type coercion
> 3. The RFC was poorly structured
>
> In hindsight I understand why I had a hard time writing the RFC. I
> tried making a case against the switch statement while really not
> addressing the switch statement at all. The new RFC proposes a match
> expression that fixes all the objections raised against the switch
> statement. Additionally, match arms can now contain statement lists
> which allows you to use the match expression anywhere the switch
> statement would have been used previously.
>
> While some people have suggested statement lists aren't necessary I
> don't think it makes sense to raise objections against the switch
> statement without offering an alternative.
>
> I also experimented with pattern matching but decided against it. The
> exact reason is described in the RFC.
>
> I'm now confident this is the right approach. I hope you will be
> happier with this proposal.
>
> Happy Easter!
This is a substantial improvement over the previous RFC, thank you!
1) The use of => is fine with me. I'm not bothered by it, but I'm also open to
other options like : if there's a strong consensus otherwise.
2) I am also still against block statements in the right-hand side, largely for
the same reasons as Rowan. They're unnecessary and lead to confusion. In my
mind, match expressions are more like a multi-branch ternary than a switch
statement.
When I say unnecessary, I mean that very literally. Because it can take any
expression, that means it can simply execute a pre-defined function or
anonymous function.
function b() {
// Something multi-line and complicated.
}
$c = function ($x) {
// Something multi-line and complicated.
};
match ($x) {
1 => 'A',
2 => b(),
3 => $c($x),
};
That not only alleviates the need to support multi-line blocks, it keeps the
match statement itself clearer to understand at-a-glance, and encourages the
definition of named, testable, small blocks of code (ie, functions whether
anonymous or not), which is a net win on its own. The overall effect is the
same.
And if you really, really need to inline the block for some reason, this is
ugly but syntactically valid:
match ($x) {
1 => 'A',
2 => b(),
3 => function() use ($whatever) {
// Something multi-line and complicated.
}(),
};
(Incidentally, the same "factor complex expressions out to a function an
everyone is better off" applies to the left hand side, too. That's a good
thing.)
I would strongly recommend removing the block statement support, as it just
muddies the water.
3) I'm fine with match() always being strict comparison, regardless of the type
mode. However, it should probably be made more explicit in the RFC that it is
unaffected by the type mode.
4) Possible addition: Make the match input optional, defaulting to "true".
That is:
match (true) {
$x < 5 => 'A',
$x > 10 => 'B',
$x ==7 => 'C',
default => 'D',
}
Can be shortened to:
match {
$x < 5 => 'A',
$x > 10 => 'B',
$x ==7 => 'C',
default => 'D',
}
Since it's an expression it still has all the values available from the scope,
so it's just as capable and saves a little typing in that case.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
