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 expres
Hi Rowan
If we were to remove blocks we'd probably also reconsider other things
(namely the optional semicolon and break/continue) and many examples
in the RFC would become invalid and irrelevant. This would probably
lead to even more confusion which is why I will most likely not move
blocks to an
On 20/04/2020 19:19, Ilija Tovilo wrote:
Just a heads up, I'd like to start the voting on the match expression
RFC in a couple of days.
https://wiki.php.net/rfc/match_expression
I have made a number of changes to the RFC.
* Block return values are now allowed but limited to match arms
(https:
Hi Ilija,
On Sun, Apr 12, 2020 at 2:16 AM Ilija Tovilo wrote:
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
I know I'm a l
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 expressi
Hi Nikita
> I think part of the problem is that it's a case of either / or.
I agree that your example is an unpleasant limitation.
> 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
> current
On Sun, Apr 12, 2020 at 2:16 AM Ilija Tovilo wrote:
> Hi internals
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>
> Due to
Hi Rowan
> Then why not introduce the match expression first, and add block
> expressions (as a general concept) later?
Mainly because I fear it won't pass and we'll end up with a
handicapped match expression that can't be used half the time.
> That way, we don't need all the special restriction
> Please, pull that part out.
Guys. You've made your opinions loud and clear. But I'm not just
building this for you, I'm also building it for others and myself.
> With it, it may pass or not, but it would be a weaker proposal.
Maybe, maybe not. You're assuming people will share your opinion but
On Mon, Apr 13, 2020, at 10:08 AM, David Rodrigues wrote:
> With all the humility of the world and without wanting to be exhaustive
> about this, my only question is why can't we keep it as a switch, instead
> of creating a new keyword?
That was the original proposal. The main issue came down to
But when we do:
function x() {
$a = function () { return 123; }
}
We know that "return" here is for the current function () scope, and not
for the parents one. So "return" inside inlined-switch should be used to
specify the switch return itself. Seems clear to me.
Atenciosamente,
David Rodri
With all the humility of the world and without wanting to be exhaustive
about this, my only question is why can't we keep it as a switch, instead
of creating a new keyword?
$x = switch ($y) {
case 0: return 1;
case 1: return 20;
// default: return null;
};
I say this because, in the f
On 13/04/2020 12:28, Ilija Tovilo wrote:
It would be possible for the blocks to return values (though not with
the return keyword).
[...]
We can't do everything at once.
Then why not introduce the match expression first, and add block
expressions (as a general concept) later? That way, we do
> Firstly, block expressions are a foundational part of the Rust
> language, not a special case used in only one place.
>From a previous e-mail:
> It would be possible for the blocks to return values (though not with
> the return keyword). I've created a small prototype a few weeks ago:
>
> https
On 13 April 2020 09:38:10 BST, Ilija Tovilo 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 w
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 on
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
Hi Larry
> That not only alleviates the need to support multi-line blocks, it keeps the
> match statement itself clearer to understand at-a-glance, and encourages the
> definition of named, testable, small blocks of code (ie, functions whether
> anonymous or not), which is a net win on its own.
Hi Rowan
> 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.
> Can I mix a bare value and a block as arms of the same match, or does the
> whole construct need to
On Sat, Apr 11, 2020, at 7:16 PM, Ilija Tovilo wrote:
> Hi internals
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>
> Due
I love everything about this, except for one deal killer.
I love the use of =>. And I love the blocks.
Plus I love that it can fully replace switch because of how using switch can
easily allow an developer's oversight to introduce subtle bugs.
The deal killer IMO is this:
"match was added a
>> Would be posible for blocks to require a return statement instead of raising
>> an error?
>
>It would be possible for the blocks to return values (though not with
>the return keyword). I've created a small prototype a few weeks ago:
>
>```
>$result = match ($x) {
>0 => {
>echo 'Foo'
On 12 April 2020 01:16:04 BST, Ilija Tovilo wrote:
>Hi internals
>
>I'd like to announce the match expression RFC that replaces the switch
>expression RFC I announced a few weeks ago.
>New: https://wiki.php.net/rfc/match_expression
>Old: https://wiki.php.net/rfc/switch_expression
Hi Ilija,
Thank
Hi Iván
> Would be posible for blocks to require a return statement instead of raising
> an error?
It would be possible for the blocks to return values (though not with
the return keyword). I've created a small prototype a few weeks ago:
```
$result = match ($x) {
0 => {
echo 'Foo';
> Hi internals
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>
> Due to the feedback I decided to take the RFC in a slightly
Hi George
I appreciate your feedback.
> One small decision that I personally disagree with is the usage of `=>`
> compared to using the colon as the switch statement does.
I picked the `=>` symbol because IMO the extra spacing and wider
symbol visually separates the two sides better. The differ
On Sun, 12 Apr 2020 at 02:16, Ilija Tovilo wrote:
> Hi internals
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>
> Due to t
Hi internals
I'd like to announce the match expression RFC that replaces the switch
expression RFC I announced a few weeks ago.
New: https://wiki.php.net/rfc/match_expression
Old: https://wiki.php.net/rfc/switch_expression
Due to the feedback I decided to take the RFC in a slightly different
dire
28 matches
Mail list logo
