Hi!
I'm not quite sure what the way forward regarding that is. I can understand
the reluctance to propose the Rust-style block expression syntax, given its
Speaking of which, what is the problem with that? I mean, if we just
declare that the value of a block is the return of the last expression,
would it break anything? Of course, by itself it'd be useless since we
still aren't using blocks as expressions. But if we then had constructs
that could accept both blocks and expressions - and we don't need to
make everything that accepts expressions to accept blocks - we just need
to make it make sense in those "dual" constructs.
I think that introducing a new construct like that would require its own RFC
Especially since there is a lot of confusion around how those blocks
should work.
Eg. why should the fact that I use or not a semicolon depend on the fact
what I will do with return value of the expression.
I think a much more sane solution would be to only allow expressions in
match.
$x = match(true) {
$a === 1 => foo(),
$b > 2 => bar(),
}
$a = match($a) {
1 => foo(),
2 => bar(),
}
And then a block could be just an alias for a self calling anonymous
function with all of its consequences:
- continue and break forbidden
- return being the keyword used to match the result instead of missing
semicolon
- if no return was provided result defaults to null
- etc.
eg. this two are equal statements assigning result of baz() to $y:
$y = match($x) {
1 => {
foo();
bar();
return baz();
},
...
}
$y = match($x) {
1 => function() use(everything) {
foo();
bar();
return baz();
}(),
...
}
Also I think that suggestion that someone already made about making the
parameter default to true is a really god idea,
I even believe that statements in this form are probably going to be
more common than the standard one:
$y = match {
$a < 10 => foo(),
$a < 20 => bar(),
...
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
