Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
I really think that the implicit `match (true) {` is an easily understood
behavior.
On Fri, Jun 18, 2021 at 11:04 AM Guilliam Xavier
wrote:
> On Fri, Jun 18, 2021 at 4:24 PM Larry Garfield
> 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;
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
On Fri, Jun 18, 2021 at 4:24 PM Larry Garfield
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
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
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 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;
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
On Fri, May 22, 2020 at 4:09 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
>
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
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
Hey Ilija, On Fri, May 22, 2020 at 1:08 PM Ilija Tovilo 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/
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
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
[PHP-DEV] [RFC][DISCUSSION] Match expression v2
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
