On 12/04/2020 21:16, Ilija Tovilo wrote:
Can match arms contain other flow control, such as "return" or "continue"?
Yes and yes. They behave exactly the same as in the switch. This
should definitely be described in the RFC.
You didn't quote the second part of that question, which admittedly was
a bit rhetorical, but important: allowing these rules out using either
of those keywords in future extensions of this syntax. That means if we
want to add a way to get a value out of a statement block, we can't use
"return"; and if we want to add explicit fallthrough, we can't use
"continue".
Also note that in switch, "continue" and "break" are actually synonyms,
both jumping to the end of the switch block (see also
https://wiki.php.net/rfc/continue_on_switch_deprecation). I'm not sure
that's actually all that intuitive or useful in the proposed match
statement.
Can I mix a bare value and a block as arms of the same match, or does the whole construct need to
be in either "expression form" or "statement form"?
Yes, you can mix blocks and expressions given you don't use the return
value of the whole match expression.
Again, you skipped the second part of the question - will this make
sense to users? What error message will they get if they write this:
$x = match($y) { 1 => "Hello", 2 => "Goodbye", 3 => { throw new
Exception; } };
(If https://wiki.php.net/rfc/throw_expression passes, then "3 => throw
new Exception" without the braces will presumably be valid, but that
just makes it even more confusing, IMO.)
Can I omit the trailing semicolon even in "expression form"
Yes.
So this would be valid PHP?
$x = match($y) { 1 => "Hello", 2 => "Goodbye" } echo $y;
To clarify what's going on here: There's no statement variant of
the match expression [...]
I don't think users will see it that way. An "expression" where you
can't use the result (but can use flow control like "throw" and
"return") feels very much like a statement, regardless of how the parser
defines it.
... because I noticed that I kept forgetting to add it in my tests.
I think needing to add a special case to the grammar is a sign that the
proposed syntax doesn't fit well with the rest of the language. Did you
ever forget to put the semicolon when using it in expression context, or
only when using statement blocks?
As mentioned in my announcement IMO it doesn't make sense criticizing
the switch statement but then not offering an alternative.
I don't think this is true. If you were proposing "foreach", you might
criticize the "for" statement, but that doesn't mean you'd extend
"foreach" so that it could replace every single "for" statement.
To reiterate, I think the match expression - with no statement blocks -
stands up really well as a replacement for those switch statements where
you're deciding on a value, and for nested ternaries (which are pretty
much unused in PHP due to the broken precedence).
Other proposals can replace other uses of switch, or switch can live on
with more limited use - after all, we even have a "goto" statement in
PHP, for those rare occasions where *none* of the built-in flow control
is good enough.
To respond to something you said to Larry:
People can't be forced into
writing clean code and my fear here is that they will just revert back
to using what is more convenient.
That's their loss! Whether or not "match" supports blocks, some people
won't use it, just as some people write unnecessarily complicated if
statements because they don't spend the time structuring them with
elseif or switch.
My concern is that if match supports blocks, but the syntax and
behaviour is unintuitive, we'll be stuck with another feature that
nobody likes very much but we can't easily replace. Worse, the RFC might
lose support based on that part, and we'd miss out on getting a really
nice new expression.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
