On 13 April 2020 09:38:10 BST, Ilija Tovilo <[email protected]> wrote:
>It's described in the RFC:
>
>//> Fatal error: Match expressions that utilize the result value can't
>contain statement lists
Thanks, I missed that. Reasonably clear, I guess, although I imagine there'll
be questions on Stack Overflow asking what a "statement list" is.
>> So this would be valid PHP?
>>
>> $x = match($y) { 1 => "Hello", 2 => "Goodbye" } echo $y;
>
>No. A semicolon is needed. Here the semicolon belongs to the
>assignment, not the match.
...
>The only case where expression statement doesn't require a semicolon is
>here:
>
>* Expression statement <- Doesn't require a semicolon
> * match
Right, so I go back to my earlier point that there are basically two forms of
match proposed:
- one where you can use it anywhere an expression is expected, with no
statement blocks
- one which can be used as a standalone statement, which can contain statement
blocks, and which doesn't need a trailing semicolon
>> 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.
>
>I find it odd that people keep referring to Rust but apparently have
>no clue how it works. This is precisely what they do.
>
>https://doc.rust-lang.org/reference/statements.html#expression-statements
I didn't mention Rust, and am fully aware that I don't know how its syntax
works. What I said was that the proposed syntax doesn't fit into PHP easily.
Two things stand out to me following that link:
Firstly, block expressions are a foundational part of the Rust language, not a
special case used in only one place. They're used as the basis for everything
from if statements to async blocks, all of which evaluate to a value. That's a
really neat design feature, but not something that exists in PHP.
It also makes the semicolon rule somewhat more natural: it makes *all* the
control flow blocks in Rust feel more natural to developers coming from other
languages. It's not an ad hoc rule for one expression, it's a general rule
across the language.
Secondly, the page you linked calls out an ambiguity caused by omitting the
semicolon, which would apply equally in PHP:
match($x) { 1 => ['foo', 'bar'] }
[0];
It then explains the important restriction of only omitting the semicolon if
the result is void/null rather than a concrete value. An equivalent in PHP
would be to only allow omitting the semicolon if every arm of the match is a
statement list, further distinguishing the expression and statement forms.
> I think this RFC
>satisfies your needs. It has some extra parts you don't need, and
>that's fine.
Just to be clear, that may be fine with you, but if I had a vote, I would
probably vote no to the current proposal, because I actively dislike the
proposed syntax and semantics of statement blocks. They "poison the barrel" for
me. That's a real shame, because I really like the core of the proposal.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
