Re: [DISCUSSION] Match expression

On 13 April 2020 09:38:10 BST, Ilija Tovilo <tovilo.ilija@gmail.com> 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]