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
Hi internals
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2The 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/filesI 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_proposalsThat 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
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
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
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
Hey Ilija,
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
Hi internals
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2The 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/filesI 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_proposalsThat 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
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
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 internals
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2Small 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
--
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
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
Hi Björn
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2I 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
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
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
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
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.
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
--
To unsubscribe, visit: https://www.php.net/unsub.php
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
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?
r//Björn L
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
matchconstruct 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
Hey,
Hi Benas
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2Then 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 usematchconstruct 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
--
To unsubscribe, visit: https://www.php.net/unsub.php
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
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
On Tue, 23 Jun 2020 at 09:54, Björn Larsson bjorn.x.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]
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