Hi Rowan
> 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".
And we probably shouldn't do that. return means return from the
function, it makes little sense to change it in one specific context.
We'd either need a different keyword (like pass) or some syntax that
doesn't require a keyword at all (like the block expressions I've
mentioned). The same goes for continue. A keyword like fallthrough
would be much more fitting.
> 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; } };
It's described in the RFC:
//> Fatal error: Match expressions that utilize the result value can't
contain statement lists
> 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 parsing would be done somewhat like
this:
* Expression statement <- Requires a semicolon
* Assignment
* $x
* match
The only case where expression statement doesn't require a semicolon is here:
* Expression statement <- Doesn't require a semicolon
* match
Because match is found directly under the expression statement.
> 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
ExpressionStatement :
ExpressionWithoutBlock ;
| ExpressionWithBlock
A lot of our last conversation is repeating and very little new has
been said. The only productive thing is to move on. I think this RFC
satisfies your needs. It has some extra parts you don't need, and
that's fine.
Thanks again for taking the time to read the RFC and provide your feedback!
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
