Re: [RFC][DISCUSSION] Match expression v2

This is only part of a thread. view whole thread
  110396
June 5, 2020 22:09 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi internals

> I'd like to announce the match expression v2 RFC: > https://wiki.php.net/rfc/match_expression_v2
Small reminder: Two weeks have passed since I announced the match v2 RFC with little new discussion. I'll leave it open for another two weeks and put it to a vote then if there are no objections. I will send another reminder one day before I do. Ilija
  110415
June 8, 2020 06:13 sarkedev@gmail.com (Peter Stalman)
On Fri, Jun 5, 2020 at 3:10 PM Ilija Tovilo ilija@gmail.com> wrote:
> > Hi internals > > > I'd like to announce the match expression v2 RFC: > > https://wiki.php.net/rfc/match_expression_v2 > > Small reminder: Two weeks have passed since I announced the match v2 > RFC with little new discussion. I'll leave it open for another two > weeks and put it to a vote then if there are no objections. I will > send another reminder one day before I do. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I really like this addition. 👍 It's a great way to decrease code verbosity without getting in the way of anything else. Much better without the blocks too, since with blocks you might as well use functions or `switch`. I see you mentioned pattern matching, but I think this can be done quite well in userland. Have you thought about including ranges, greater/less than, or some form of `in_array()` matching? As for making the `(true)` optional, even though many are in favour of it. to me that seems like something that would happen when/if the `while (true)` becomes optional. There's a million examples of the latter on github, and I think it would be odd to make this optional while (no pun intended) the `while` one would not be. Thanks, Peter
  110600
June 16, 2020 15:17 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2020-06-06 kl. 00:09, skrev Ilija Tovilo:

> Hi internals > >> I'd like to announce the match expression v2 RFC: >> https://wiki.php.net/rfc/match_expression_v2 > Small reminder: Two weeks have passed since I announced the match v2 > RFC with little new discussion. I'll leave it open for another two > weeks and put it to a vote then if there are no objections. I will > send another reminder one day before I do. > > Ilija
Hi, I do like this RFC and have one comment. Would it be suitable to have : as a separator instead of =>? When reading the Future scope of the RFC I noted that arrow functions was part of that, so are we here overloading the usage of the '=>' symbol? r//Björn L
  110602
June 16, 2020 16:17 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi Björn

>>> I'd like to announce the match expression v2 RFC: >>> https://wiki.php.net/rfc/match_expression_v2 > > I do like this RFC and have one comment. Would it be suitable > to have : as a separator instead of =>?
`=>` is usually used in combination expressions (arrays, yield, arrow functions). `:` is mostly used for switch cases and the alternative control structure syntax [1]. `=>` also visually separates the condition and expression better IMO. This has been suggested once before but that's not enough for me to change it at this point.
> When reading the Future scope of the RFC I noted that arrow > functions was part of that, so are we here overloading the usage > of the '=>' symbol?
The future scope mentions possible block support for arrow functions in the future (`fn() => {}`) but we use arrows or colons in match doesn't matter. Thanks for your feedback! :) Ilija [1] https://www.php.net/manual/en/control-structures.alternative-syntax.php
  110634
June 17, 2020 14:48 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2020-06-16 kl. 18:17, skrev Ilija Tovilo:
> Hi Björn > >>>> I'd like to announce the match expression v2 RFC: >>>> https://wiki.php.net/rfc/match_expression_v2 >> I do like this RFC and have one comment. Would it be suitable >> to have : as a separator instead of =>? > `=>` is usually used in combination expressions (arrays, yield, arrow > functions). `:` is mostly used for switch cases and the alternative > control structure syntax [1]. `=>` also visually separates the > condition and expression better IMO. This has been suggested once > before but that's not enough for me to change it at this point.
Well one could argue that when working with legacy code containing switch statements where one gradually migrates to match, it might be easier to have the same separator, i.e. ":". Is the proposed => separator inspired by Rust or Scala? Checked what other languages used and  for switch it's ":" of course. So one might argue that to align with match statements in other languages "=>" is a good choice, but OTOH if ones sees match as an enhanced switch, having ":" as a separator is another alternative. Anyway, I think it would be good if the RFC is updated with what other languages uses, since that is a good motivation for why using "=>" as a separator. What bothered me a little with that selection is the usage of the "=>" symbol for other things in PHP. Hint, I was a fan of the "==>" for arrow functions ;-) r//Björn L
  110675
June 18, 2020 20:51 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi Björn

>> I'd like to announce the match expression v2 RFC: >> https://wiki.php.net/rfc/match_expression_v2
> Well one could argue that when working with legacy code containing > switch statements where one gradually migrates to match, it might be > easier to have the same separator, i.e. ":".
I think that's somewhat of a moot point. The syntax of match is quite different (match instead of switch, no case, no break, colon instead of case, comma instead of semicolon, trailing semicolon). Just making one of those the same doesn't make a meaningful difference for ease of migration.
> Is the proposed => separator inspired by Rust or Scala? Checked what > other languages used and for switch it's ":" of course. So one might > argue that to align with match statements in other languages "=>" is > a good choice, but OTOH if ones sees match as an enhanced switch, > having ":" as a separator is another alternative.
Since nobody else asked for it, just for you I compiled a list of other languages :) https://gist.github.com/iluuu1994/11ac292cf7daca8162798d08db219cd5 The conclusion: Most languages also use some form of arrow. It makes sense to me to stay consistent with those languages. Ilija
  110695
June 22, 2020 15:35 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:

> Hi Björn > >>> I'd like to announce the match expression v2 RFC: >>> https://wiki.php.net/rfc/match_expression_v2 >> Well one could argue that when working with legacy code containing >> switch statements where one gradually migrates to match, it might be >> easier to have the same separator, i.e. ":". > I think that's somewhat of a moot point. The syntax of match is quite > different (match instead of switch, no case, no break, colon instead > of case, comma instead of semicolon, trailing semicolon). Just making > one of those the same doesn't make a meaningful difference for ease of > migration. Agree on that! One thing though. Is semicolon mandatory or is it optional
like in the first RFC? Feels a bit odd with a semicolon after a curly bracket.
>> Is the proposed => separator inspired by Rust or Scala? Checked what >> other languages used and for switch it's ":" of course. So one might >> argue that to align with match statements in other languages "=>" is >> a good choice, but OTOH if ones sees match as an enhanced switch, >> having ":" as a separator is another alternative. > Since nobody else asked for it, just for you I compiled a list of > other languages :) > > https://gist.github.com/iluuu1994/11ac292cf7daca8162798d08db219cd5 > > The conclusion: Most languages also use some form of arrow. It makes > sense to me to stay consistent with those languages. > > Ilija
I think this is a very good motivation on why select => as a symbol and I'm glad it's listed in the RFC. r//Björn
  110697
June 22, 2020 16:05 benas.molis.iml@gmail.com (Benas IML)
On Mon, Jun 22, 2020, 6:35 PM Björn Larsson larsson@telia.com>
wrote:

> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo: > > > Hi Björn > > > >>> I'd like to announce the match expression v2 RFC: > >>> https://wiki.php.net/rfc/match_expression_v2 > >> Well one could argue that when working with legacy code containing > >> switch statements where one gradually migrates to match, it might be > >> easier to have the same separator, i.e. ":". > > I think that's somewhat of a moot point. The syntax of match is quite > > different (match instead of switch, no case, no break, colon instead > > of case, comma instead of semicolon, trailing semicolon). Just making > > one of those the same doesn't make a meaningful difference for ease of > > migration. > Agree on that! One thing though. Is semicolon mandatory or is it optional > like in the first RFC? Feels a bit odd with a semicolon after a curly > bracket. >
It's mandatory since it's an expression, not a block. Another example of an expression would be a closure: ``` $fn = function () { ... }; // a semicolon is mandatory here. ```
>> Is the proposed => separator inspired by Rust or Scala? Checked what > >> other languages used and for switch it's ":" of course. So one might > >> argue that to align with match statements in other languages "=>" is > >> a good choice, but OTOH if ones sees match as an enhanced switch, > >> having ":" as a separator is another alternative. > > Since nobody else asked for it, just for you I compiled a list of > > other languages :) > > > > https://gist.github.com/iluuu1994/11ac292cf7daca8162798d08db219cd5 > > > > The conclusion: Most languages also use some form of arrow. It makes > > sense to me to stay consistent with those languages. > > > > Ilija > > I think this is a very good motivation on why select => as a symbol and > I'm glad it's listed in the RFC. > > r//Björn > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  110701
June 23, 2020 08:23 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2020-06-22 kl. 18:05, skrev Benas IML:

> On Mon, Jun 22, 2020, 6:35 PM Björn Larsson larsson@telia.com> > wrote: > >> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo: >> >>> Hi Björn >>> >>>>> I'd like to announce the match expression v2 RFC: >>>>> https://wiki.php.net/rfc/match_expression_v2 >>>> Well one could argue that when working with legacy code containing >>>> switch statements where one gradually migrates to match, it might be >>>> easier to have the same separator, i.e. ":". >>> I think that's somewhat of a moot point. The syntax of match is quite >>> different (match instead of switch, no case, no break, colon instead >>> of case, comma instead of semicolon, trailing semicolon). Just making >>> one of those the same doesn't make a meaningful difference for ease of >>> migration. >> Agree on that! One thing though. Is semicolon mandatory or is it optional >> like in the first RFC? Feels a bit odd with a semicolon after a curly >> bracket. >> > It's mandatory since it's an expression, not a block. Another example of an > expression would be a closure: > > ``` > $fn = function () { > ... > }; // a semicolon is mandatory here. > ```
Absolutely so. I was thinking of the case mentioned in v1 RFC when it's used as a stand-alone expression. match ($y) { .... };  ` Optional? r//Björn L
  110703
June 23, 2020 08:30 benas.molis.iml@gmail.com (Benas IML)
On Tue, Jun 23, 2020, 11:23 AM Björn Larsson larsson@telia.com>
wrote:

> Den 2020-06-22 kl. 18:05, skrev Benas IML: > > > On Mon, Jun 22, 2020, 6:35 PM Björn Larsson larsson@telia..com> > > wrote: > > > >> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo: > >> > >>> Hi Björn > >>> > >>>>> I'd like to announce the match expression v2 RFC: > >>>>> https://wiki.php.net/rfc/match_expression_v2 > >>>> Well one could argue that when working with legacy code containing > >>>> switch statements where one gradually migrates to match, it might be > >>>> easier to have the same separator, i.e. ":". > >>> I think that's somewhat of a moot point. The syntax of match is quite > >>> different (match instead of switch, no case, no break, colon instead > >>> of case, comma instead of semicolon, trailing semicolon). Just making > >>> one of those the same doesn't make a meaningful difference for ease of > >>> migration. > >> Agree on that! One thing though. Is semicolon mandatory or is it > optional > >> like in the first RFC? Feels a bit odd with a semicolon after a curly > >> bracket. > >> > > It's mandatory since it's an expression, not a block. Another example of > an > > expression would be a closure: > > > > ``` > > $fn = function () { > > ... > > }; // a semicolon is mandatory here. > > ``` > > Absolutely so. I was thinking of the case mentioned in v1 RFC when it's > used > as a stand-alone expression. > match ($y) { > ... > }; > Then it's not a standalone expression but a block. In this case, you cannot
add an optional semicolon at all. But this RFC v2 is not proposing to add a block, therefore you won't be allowed to use `match` construct as a standalone expression anyways. ` Optional?
> > r//Björn L >
  110704
June 23, 2020 08:34 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi Benas

>> I'd like to announce the match expression v2 RFC: >> https://wiki.php.net/rfc/match_expression_v2
> Then it's not a standalone expression but a block. In this case, you cannot add an optional semicolon at all. > > But this RFC v2 is not proposing to add a block, therefore you won't be allowed to use `match` construct as a standalone expression anyways.
Using match as a standalone expression is definitely allowed, just like any other expression. // This is fine, the semicolon is required match ($foo) { $bar => baz(), }; Ilija
  110705
June 23, 2020 08:39 benas.molis.iml@gmail.com (Benas IML)
Hey,

On Tue, Jun 23, 2020, 11:34 AM Ilija Tovilo ilija@gmail.com> wrote:

> Hi Benas > > >> I'd like to announce the match expression v2 RFC: > >> https://wiki.php.net/rfc/match_expression_v2 > > > Then it's not a standalone expression but a block. In this case, you > cannot add an optional semicolon at all. > > > > But this RFC v2 is not proposing to add a block, therefore you won't be > allowed to use `match` construct as a standalone expression anyways. > > Using match as a standalone expression is definitely allowed, just > like any other expression. > > // This is fine, the semicolon is required > match ($foo) { > $bar => baz(), > }; >
Yup but it won't return you out of the function. For example, this wouldn't work: ``` function test(int $value): bool { match($value) { 0 => false, 1 => true } } $test = test(1); ``` But it seems by standalone expressions, Bjorn meant your example. Sorry for the confusion, I thought he was referring to blocks.
> Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  110702
June 23, 2020 08:30 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi Björn

>> I'd like to announce the match expression v2 RFC: >> https://wiki.php.net/rfc/match_expression_v2
> Absolutely so. I was thinking of the case mentioned in v1 RFC when it's used > as a stand-alone expression. > match ($y) { > ... > }; > ` Optional?
In this RFC the semicolon is required. Many people thought the grammar rules for the optional semicolon were confusing which is why I dropped that feature in this RFC. Ilija
  110706
June 23, 2020 08:54 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2020-06-23 kl. 10:30, skrev Ilija Tovilo:

> Hi Björn > >>> I'd like to announce the match expression v2 RFC: >>> https://wiki.php.net/rfc/match_expression_v2 >> Absolutely so. I was thinking of the case mentioned in v1 RFC when it's used >> as a stand-alone expression. >> match ($y) { >> ... >> }; >> ` Optional? > In this RFC the semicolon is required. Many people thought the grammar > rules for the optional semicolon were confusing which is why I dropped > that feature in this RFC. > > Ilija
Ok, thanks for the clarification. The reason for me to bring this up is that I was pondering on if this is the only place in PHP where a semicolon is required after a curly bracket when not used in an expression. If so I a counter argument could that it it is confusing for programmers, not so privy to all the ins and outs of PHP. Anyway, maybe a feature to consider for a future 8.1 RFC. r//Björn
  110709
June 23, 2020 12:09 rowan.collins@gmail.com (Rowan Tommins)
On Tue, 23 Jun 2020 at 09:54, Björn Larsson larsson@telia.com>
wrote:

> > Ok, thanks for the clarification. The reason for me to bring > this up is that I was pondering on if this is the only place in > PHP where a semicolon is required after a curly bracket > when not used in an expression. >
Two things: - as proposed here, match is *always* an expression; it just happens that PHP lets you throw away the result of an expression, so "match($x){};" is a valid statement for the same reason "42;" is a valid statement - as Ilija mentioned, ending a statement with an anonymous function also leads to the combination "};" function returnsFunc() { return function() { echo "Hello, world!\n"; }; } function returnsMatchResult($x) { return match($x) { 1=> "Hello", 2=>"world" }; } I'd also note that while there aren't currently many cases where it would be ambiguous whether a statement or expression was intended, new ones might be added in future. For instance, post-fix conditionals (like in Perl and Ruby) would give us match($x) { ... } if $condition; This kind of syntax short-cut tends to end up with complex rules of "it's optional except when it's not", which I'm personally not a fan of. Regards, -- Rowan Tommins [IMSoP]
  110618
June 17, 2020 08:30 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi internals

> I'd like to announce the match expression v2 RFC: > https://wiki.php.net/rfc/match_expression_v2
Last reminder: I'm opening the vote on Friday. The vote is going to be a straightforward yes/no vote. Ilija