On 01/04/2020 09:56, Rowan Tommins wrote:
If the intention is to make this feel like an expression version of the switch
statement, then making it look more similar would make sense.
To expand on this a bit, if the aim is "a switch statement, but usable
as an expression", then it would make sense to start with an identical
syntax, and make only those changes needed to meet that aim.
So, given the following example from the RFC:
switch ($x) {
case 0:
$y = 'Foo';
break;
case 1:
$y = 'Bar';
break;
case 2:
$y = 'Baz';
break;
}
The starting point would be to move the assignments and nothing else:
$y = switch ($x) {
case 0:
'Foo';
break;
case 1:
'Bar';
break;
case 2:
'Baz';
break;
}
That looks a little odd, because the result expressions are formatted as
statements, so we could maybe combine them with the break keyword:
$y = switch ($x) {
case 0:
break 'Foo';
case 1:
break 'Bar';
case 2:
break 'Baz';
}
We could then bikeshed whether to swap out "break" for "return" or
"yield", but the result would look and act like an expression version of
the switch statement. It could even have other statements between the
"case" and "break" lines, and all the normal fallthrough behaviour.
The other issues discussed in your RFC - fallthrough, inexhaustiveness,
type coercion - are valuable things to discuss, but each one takes this
further away from being a "switch expression", and into being "a new
value-matching expression". As I said in my last e-mail, I don't think
that's a bad thing; I really like the proposed syntax, as a new
construct for picking one of a set of expressions, and would be happy to
see the RFC re-focussed in that direction.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
