[RFC][DISCUSSION] Match expression v2

php.internals

Ilija Tovilo

6 years ago
Hi internals I'd like to announce the match expression v2 RFC: https://wiki.php.net/rfc/match_expression_v2 The goal of the new draft is to be as simple and uncontroversial as possible. It differs from v1 in the following ways: * Blocks were removed * Secondary votes were removed * optional semicolon * omitting `(true)` * Unimportant details were removed (e.g. examples for future scope) You can look at the diff here: https://github.com/iluuu1994/match-expression-rfc/pull/8/files I will also leave the discussion period open for longer as that too was one of the primary criticisms. As mentioned by Kalle:
> Resurrecting rejected RFCs have a "cooldown" of 6 months: > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
That is, unless:
> The author(s) make substantial changes to the proposal. While it's > impossible to put clear definitions on what constitutes 'substantial' > changes, they should be material enough so that they'll significantly > affect the outcome of another vote.
Given that many people have said without blocks they'd vote yes I'd say this is the case here. Let me know if you don't agree. Ilija

Larry Garfield

6 years ago
On Fri, May 22, 2020, at 6:08 AM, Ilija Tovilo wrote:
> Hi internals > > I'd like to announce the match expression v2 RFC: > https://wiki.php.net/rfc/match_expression_v2 > > The goal of the new draft is to be as simple and uncontroversial as > possible. It differs from v1 in the following ways: > > * Blocks were removed > * Secondary votes were removed > * optional semicolon > * omitting `(true)` > * Unimportant details were removed (e.g. examples for future scope) > > You can look at the diff here: > https://github.com/iluuu1994/match-expression-rfc/pull/8/files > > I will also leave the discussion period open for longer as that too > was one of the primary criticisms. > > As mentioned by Kalle: > > > Resurrecting rejected RFCs have a "cooldown" of 6 months: > > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals > > That is, unless: > > > The author(s) make substantial changes to the proposal. While it's > > impossible to put clear definitions on what constitutes 'substantial' > > changes, they should be material enough so that they'll significantly > > affect the outcome of another vote. > > Given that many people have said without blocks they'd vote yes I'd > say this is the case here. Let me know if you don't agree. > > Ilija
I'd say this is a textbook example of sufficiently "substantial." Thanks, Ilija! This looks a lot better. My one question is why you're not including the implicit "match (true)" in this version, when the secondary vote on the previous RFC was 80% in favor of it. (And I still think the argument is stronger if you include a comparison to ternary assignment, but that doesn't affect implementation.) --Larry Garfield

Ilija Tovilo

6 years ago
Hi Larry
> My one question is why you're not including the implicit "match (true)" > in this version, when the secondary vote on the previous RFC was > 80% in favor of it.
I received quite a bit of feedback that the RFC was too complex. I tried to make the RFC simpler by removing all non-essential parts. I'm ready to create a follow up RFC for this (although it would probably not make PHP 8.0).
> (And I still think the argument is stronger if you include a comparison > to ternary assignment, but that doesn't affect implementation.)
Makes sense, I will incorporate an example :) Ilija

Larry Garfield

6 years ago
On Fri, May 22, 2020, at 10:42 AM, Ilija Tovilo wrote:
> Hi Larry > > > My one question is why you're not including the implicit "match (true)" > > in this version, when the secondary vote on the previous RFC was > > 80% in favor of it. > > I received quite a bit of feedback that the RFC was too complex. I > tried to make the RFC simpler by removing all non-essential parts. I'm > ready to create a follow up RFC for this (although it would probably > not make PHP 8.0).
Hm. A logical argument, but given its overwhelming support before and that it's therefore almost certain to pass in the future, I don't see why it's a net win to have PHP 8.0 missing that bit. It seemed uncontroversial, and seems like a highly common use case. --Larry Garfield

Ilija Tovilo

6 years ago
Hi Larry
> > > My one question is why you're not including the implicit "match (true)" > > > in this version, when the secondary vote on the previous RFC was > > > 80% in favor of it. > > > > I received quite a bit of feedback that the RFC was too complex. I > > tried to make the RFC simpler by removing all non-essential parts. I'm > > ready to create a follow up RFC for this (although it would probably > > not make PHP 8.0). > > Hm. A logical argument, but given its overwhelming support before and that it's therefore almost certain to pass in the future, I don't see why it's a net win to have PHP 8.0 missing that bit. It seemed uncontroversial, and seems like a highly common use case.
80% were in favor of this feature but it's also worth noting that only 20 people have voted. To avoid risking another rejection and thus the RFC being delayed for a year I'd rather move the feature to a different RFC. Also, the feature being included in the first draft was a rash decision in the first place (completely my fault). There are multiple ways to deal with the value comparison (e.g. do type coercion like the switch or type-error on a non-boolean value) but they haven't been discussed at all. Ilija

Mark Tomlin

5 years ago
Please excuse the year long bump, but I was hoping to draw some more attention to the implicit "match (true)" case. I'm just a regular user of PHP, nothing too fancy, just one of the many, many people around the world who use PHP. When I first started using match statements, I thought it was a natural thing that an implicit "match (true)" would just work. I do hope that this makes it into PHP 8.1, as that seems like the most obvious next step here and it would be nice for it to make it into the very next release. That is all. Thank you very much to Ilija Tovilo for adding the match keyword to the language, and the whole PHP dev team for making this incredible language. PHP has given me a whole career, and I am deeply grateful to you all. On Fri, May 22, 2020 at 11:30 AM Larry Garfield <larry@garfieldtech.com> wrote:
> On Fri, May 22, 2020, at 6:08 AM, Ilija Tovilo wrote: > > Hi internals > > > > I'd like to announce the match expression v2 RFC: > > https://wiki.php.net/rfc/match_expression_v2 > > > > The goal of the new draft is to be as simple and uncontroversial as > > possible. It differs from v1 in the following ways: > > > > * Blocks were removed > > * Secondary votes were removed > > * optional semicolon > > * omitting `(true)` > > * Unimportant details were removed (e.g. examples for future scope) > > > > You can look at the diff here: > > https://github.com/iluuu1994/match-expression-rfc/pull/8/files > > > > I will also leave the discussion period open for longer as that too > > was one of the primary criticisms. > > > > As mentioned by Kalle: > > > > > Resurrecting rejected RFCs have a "cooldown" of 6 months: > > > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals > > > > That is, unless: > > > > > The author(s) make substantial changes to the proposal. While it's > > > impossible to put clear definitions on what constitutes 'substantial' > > > changes, they should be material enough so that they'll significantly > > > affect the outcome of another vote. > > > > Given that many people have said without blocks they'd vote yes I'd > > say this is the case here. Let me know if you don't agree. > > > > Ilija > > I'd say this is a textbook example of sufficiently "substantial." > > Thanks, Ilija! This looks a lot better. > > My one question is why you're not including the implicit "match (true)" in > this version, when the secondary vote on the previous RFC was 80% in favor > of it. > > (And I still think the argument is stronger if you include a comparison to > ternary assignment, but that doesn't affect implementation.) > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Thank you for your time, Mark 'Dygear' Tomlin;

Larry Garfield

5 years ago
On Thu, Jun 17, 2021, at 1:49 PM, Mark Tomlin wrote:
> Please excuse the year long bump, but I was hoping to draw some more > attention to the implicit "match (true)" case. I'm just a regular user of > PHP, nothing too fancy, just one of the many, many people around the world > who use PHP. When I first started using match statements, I thought it was > a natural thing that an implicit "match (true)" would just work. I do hope > that this makes it into PHP 8.1, as that seems like the most obvious next > step here and it would be nice for it to make it into the very next release. > > That is all. Thank you very much to Ilija Tovilo for adding the match > keyword to the language, and the whole PHP dev team for making this > incredible language. PHP has given me a whole career, and I am deeply > grateful to you all.
I wrote a separate small RFC for implicit-true match statements (https://wiki.php.net/rfc/short-match). There didn't seem to be a great deal of interest, though (https://externals.io/message/112496). There's not much else to do with that RFC beyond bring it to a vote and let the chips fall where they may. If folks think that's worth doing I can do so. It's not going to be able to scope creep much beyond its current minimalism. --Larry Garfield

Guilliam Xavier

5 years ago
On Fri, Jun 18, 2021 at 4:24 PM Larry Garfield <larry@garfieldtech.com> wrote:
> On Thu, Jun 17, 2021, at 1:49 PM, Mark Tomlin wrote: > > Please excuse the year long bump, but I was hoping to draw some more > > attention to the implicit "match (true)" case. I'm just a regular user of > > PHP, nothing too fancy, just one of the many, many people around the > world > > who use PHP. When I first started using match statements, I thought it > was > > a natural thing that an implicit "match (true)" would just work. I do > hope > > that this makes it into PHP 8.1, as that seems like the most obvious next > > step here and it would be nice for it to make it into the very next > release. > > > > That is all. Thank you very much to Ilija Tovilo for adding the match > > keyword to the language, and the whole PHP dev team for making this > > incredible language. PHP has given me a whole career, and I am deeply > > grateful to you all. > > I wrote a separate small RFC for implicit-true match statements ( > https://wiki.php.net/rfc/short-match). There didn't seem to be a great > deal of interest, though (https://externals.io/message/112496). > > There's not much else to do with that RFC beyond bring it to a vote and > let the chips fall where they may. If folks think that's worth doing I can > do so. It's not going to be able to scope creep much beyond its current > minimalism. >
Before going to vote, I think the RFC should be updated to at least mention the strict-VS-loose comparison choice (for things like `match { preg_match(/*...*/) => /*...*/ }`). Regards,
-- Guilliam Xavier

Mark Tomlin

5 years ago
I really think that the implicit `match (true) {` is an easily understood behavior. On Fri, Jun 18, 2021 at 11:04 AM Guilliam Xavier <guilliam.xavier@gmail.com> wrote:
> On Fri, Jun 18, 2021 at 4:24 PM Larry Garfield <larry@garfieldtech.com> > wrote: > > > On Thu, Jun 17, 2021, at 1:49 PM, Mark Tomlin wrote: > > > Please excuse the year long bump, but I was hoping to draw some more > > > attention to the implicit "match (true)" case. I'm just a regular user > of > > > PHP, nothing too fancy, just one of the many, many people around the > > world > > > who use PHP. When I first started using match statements, I thought it > > was > > > a natural thing that an implicit "match (true)" would just work. I do > > hope > > > that this makes it into PHP 8.1, as that seems like the most obvious > next > > > step here and it would be nice for it to make it into the very next > > release. > > > > > > That is all. Thank you very much to Ilija Tovilo for adding the match > > > keyword to the language, and the whole PHP dev team for making this > > > incredible language. PHP has given me a whole career, and I am deeply > > > grateful to you all. > > > > I wrote a separate small RFC for implicit-true match statements ( > > https://wiki.php.net/rfc/short-match). There didn't seem to be a great > > deal of interest, though (https://externals.io/message/112496). > > > > There's not much else to do with that RFC beyond bring it to a vote and > > let the chips fall where they may. If folks think that's worth doing I > can > > do so. It's not going to be able to scope creep much beyond its current > > minimalism. > > > > Before going to vote, I think the RFC should be updated to at least mention > the strict-VS-loose comparison choice (for things like `match { > preg_match(/*...*/) => /*...*/ }`). > > Regards, > > -- > Guilliam Xavier >
-- Thank you for your time, Mark 'Dygear' Tomlin;

Marco Pivetta

6 years ago
Hey Ilija, On Fri, May 22, 2020 at 1:08 PM Ilija Tovilo <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 > [...] > Given that many people have said without blocks they'd vote yes I'd > say this is the case here. Let me know if you don't agree. > >
This looks exactly like the construct that I'd vote for: good work! :-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Davey

6 years ago
On Fri, May 22, 2020 at 4:09 AM Ilija Tovilo <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 > > The goal of the new draft is to be as simple and uncontroversial as > possible. It differs from v1 in the following ways: > > * Blocks were removed > * Secondary votes were removed > * optional semicolon > * omitting `(true)` > * Unimportant details were removed (e.g. examples for future scope) > > You can look at the diff here: > https://github.com/iluuu1994/match-expression-rfc/pull/8/files > > I will also leave the discussion period open for longer as that too > was one of the primary criticisms. > > As mentioned by Kalle: > > > Resurrecting rejected RFCs have a "cooldown" of 6 months: > > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals > > That is, unless: > > > The author(s) make substantial changes to the proposal. While it's > > impossible to put clear definitions on what constitutes 'substantial' > > changes, they should be material enough so that they'll significantly > > affect the outcome of another vote. > > Given that many people have said without blocks they'd vote yes I'd > say this is the case here. Let me know if you don't agree. > > Ilija >
With these simplifications, I'm not entirely sure there is enough value here if the Conditional Return, Break, and Continue Statements RFC is passed. This could be written with the slightly more ugly, but serviceable: So this: $statement = match ($this->lexer->lookahead['type']) { Lexer::T_SELECT => $this->SelectStatement(), Lexer::T_UPDATE => $this->UpdateStatement(), Lexer::T_DELETE => $this->DeleteStatement(), default => $this->syntaxError('SELECT, UPDATE or DELETE'), }; could be expressed as: echo (function($match) { return $this->SelectStatement() if ($match === Lexer::T_SELECT); return $this->UpdateStatement() if ($match === Lexer::T_UPDATE); return $this->DeleteStatement() if ($match === Lexer::T_DELETE); return $this->syntaxError('SELECT, UPDATE or DELETE'); })($this->lexer->lookahead['type']); I mean, ultimately, it's equivalent to: echo (function($match) { if ($match === Lexer::T_SELECT) { return $this->SelectStatement() } if ($match === Lexer::T_UPDATE) { return $this->UpdateStatement() } if ($match === Lexer::T_DELETE) { return $this->SelectStatement() } return $this->syntaxError('SELECT, UPDATE or DELETE'); })($this->lexer->lookahead['type']); The main selling point for match is that it's more concise, I'm not convinced that the return if variant is much less concise. If you want to match more than one thing, use the OR (double pipe) operator in the if condition. Having said that… match is undeniably prettier. If we are doing this however, I'd prefer to implement Go's switch block, named match because we already have a switch. It's strict, but flexible. - Davey

Ilija Tovilo

6 years ago
Hi Davey
> I mean, ultimately, it's equivalent to: > > echo (function($match) { > if ($match === Lexer::T_SELECT) { > return $this->SelectStatement() > } > if ($match === Lexer::T_UPDATE) { > return $this->UpdateStatement() > } > if ($match === Lexer::T_DELETE) { > return $this->SelectStatement() > } > return $this->syntaxError('SELECT, UPDATE or DELETE'); > })($this->lexer->lookahead['type']); > > The main selling point for match is that it's more concise, I'm not convinced that the return if variant is much less concise. If you want to match more than one thing, use the OR (double pipe) operator in the if condition.
There is no ultimate right or wrong here. For myself, there's a lot of cognitive overhead reading the code above. For others that might not be the case. There are also some other benefits of using match, like the jumptable optimization and a smaller risk of making mistakes.
> If we are doing this however, I'd prefer to implement Go's switch block, named match because we already have a switch. It's strict, but flexible.
Since most people expressed a desire for the match expression with no blocks I wanted to introduce the expression first. After 6 months of using match opinions on blocks might change, or they might not. If we do introduce blocks match should be able to do pretty much everything Go's switch can. Ilija

Ilija Tovilo

6 years ago
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

Peter Stalman

6 years ago
On Fri, Jun 5, 2020 at 3:10 PM Ilija Tovilo <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

Björn Larsson

6 years ago
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

Ilija Tovilo

6 years ago
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

Björn Larsson

6 years ago
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

Ilija Tovilo

6 years ago
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

Björn Larsson

6 years ago
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

Benas IML

6 years ago
On Mon, Jun 22, 2020, 6:35 PM Björn Larsson <bjorn.x.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. ```

Björn Larsson

6 years ago
Den 2020-06-22 kl. 18:05, skrev Benas IML:
> On Mon, Jun 22, 2020, 6:35 PM Björn Larsson <bjorn.x.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

Ilija Tovilo

6 years ago
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

Benas IML

6 years ago
On Tue, Jun 23, 2020, 11:23 AM Björn Larsson <bjorn.x.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 <bjorn.x.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?

Ilija Tovilo

6 years ago
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