Hi internals,
I've opened voting on the match expression v2 RFC.
https://wiki.php.net/rfc/match_expression_v2
It will close on 2020-07-03.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Thu, 30 Apr 2020 at 13:18, Ilija Tovilo wrote:
> There are three potential use cases for language wide block expressions.
>
> 1. Match expressions
> 2. Arrow functions
> 3. Everything else
>
> The problem is that they all have slightly different semantics.
> [...]
>
I don't think that's actu
Hi someniatko
I think you have a firm grasp of the key issues but I don't agree with
your conclusion.
> Problem no. 2 could be addressed by
> allowing "complex" expressions consisting of, potentially, few
> statements, language-wide, solving the issue both for short closures
> and for `match`
I
meh, sorry, i top-posted by incident. I did not have the e-mails to
respond to (because i have just subscribed to the ML), therefore i
thought if i post with the same subject, my mail will add up to the
same thread.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
Hi!
I am quite new to the internals list, but wanted to say a word, to
maybe lit some light on the discussion, for you to be able to look at
it from slightly another angle.
I have noticed this whole thread arguing whether it is required or not
to support `match` keyword in an if-else-ish control-
On 29/04/2020 01:26, Larry Garfield wrote:
To that end, I'm going to refer to them as rustmatch (an expression that only
supports expressions and returns things; basically a fancier alternative to
ternary) and switchtng (a procedural branching statement that is basically
switch but with the le
On Wed, Apr 29, 2020, at 1:41 AM, Ilija Tovilo wrote:
> > Or for that matter... is anyone actually using that syntax in the wild, or
> > is it hypothetical?
>
> It's quite common in C (you can't declare variables directly in a
> switch case) so I'd guess it would be used at least by some people i
> Or for that matter... is anyone actually using that syntax in the wild, or is
> it hypothetical?
It's quite common in C (you can't declare variables directly in a
switch case) so I'd guess it would be used at least by some people in
PHP.
The worst part is that your code wouldn't throw, it woul
On Tue, Apr 28, 2020 at 6:58 PM Larry Garfield wrote:
>
> On Tue, Apr 28, 2020, at 7:37 PM, Levi Morrison via internals wrote:
> > > One issue that was discussed a few weeks ago, and led to the current
> > > syntax, was too many variations within the switch syntax; of course,
> > > trying to do
On Tue, Apr 28, 2020, at 7:37 PM, Levi Morrison via internals wrote:
> > One issue that was discussed a few weeks ago, and led to the current
> > syntax, was too many variations within the switch syntax; of course, trying
> > to do it all in one syntax is perpetuating that problem. However, I th
> One issue that was discussed a few weeks ago, and led to the current syntax,
> was too many variations within the switch syntax; of course, trying to do it
> all in one syntax is perpetuating that problem. However, I think Rowan has
> suggested a syntax that may be sufficiently self-documenti
On Tue, Apr 28, 2020, at 10:31 AM, Rowan Tommins wrote:
> On Tue, 28 Apr 2020 at 16:10, Bob Weinand wrote:
>
> > I think you should first think about why the "case" needs to exists at
> > all. In particular it exists to distinguish goto labels from the case
> > expressions in switch. With match,
On Tue, 28 Apr 2020 at 16:10, Bob Weinand wrote:
> I think you should first think about why the "case" needs to exists at
> all. In particular it exists to distinguish goto labels from the case
> expressions in switch. With match, match restricting statements (and thus
> goto labels) into { brack
> Am 28.04.2020 um 12:48 schrieb Rowan Tommins :
>
> On Tue, 28 Apr 2020 at 11:19, Ilija Tovilo wrote:
>
>>> for the control-flow statement, it feels awkward and not in
>>> keeping with the rest of the language. If they were separate proposals,
>> the
>>> statement would probably end up looki
On Tue, 28 Apr 2020 at 11:19, Ilija Tovilo wrote:
> > for the control-flow statement, it feels awkward and not in
> > keeping with the rest of the language. If they were separate proposals,
> the
> > statement would probably end up looking very different.
>
> Can you elaborate? If I made a propos
Hi Nikita
Thank you for your analysis. That's something I should've done as part
of the RFC.
I can only share my personal motivation for creating this RFC. Some
people will disagree.
> Is match intended as a replacement for switch?
To me, match is primarily a switch alternative with safer seman
On Tue, 28 Apr 2020 at 09:48, Nikita Popov wrote:
> Many people in the voting thread are calling for supporting match
> expressions only (without support for either statement form, or support
for
> block expressions). The RFC motivates the match construct as an improved
> replacement for switch, w
On Mon, Apr 27, 2020 at 3:57 PM Andrea Faulds wrote:
> Hi,
>
> I share Dan's reasons for voting against. I don't think things should go
> to a vote before the dust has settled.
>
> Regards,
> Andrea Faulds
>
Similar sentiment here. I don't think the concept has been explored
sufficiently.
Many
Hi,
I share Dan's reasons for voting against. I don't think things should go
to a vote before the dust has settled.
Regards,
Andrea Faulds
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 26/04/2020 09:15, Marco Pivetta wrote:
I'm not fine with allowing procedural code to be executed on the
right-hand-side of each match.
By enforcing only expressions to be on the right-hand-side, we get some
nice side-effects too: > I'd be voting YES on the RFC if the blocks were gone.
I con
Am 26.04.2020 um 10:15 schrieb Marco Pivetta:
By enforcing only expressions to be on the right-hand-side, we get some
nice side-effects too:
* no need to discuss `continue`
* no need to discuss `break`
* no need to discuss `return`
Overall, that would be a win-win.
Makes sense to me.
Am 25.04.2020 um 13:03 schrieb Dan Ackroyd:
I like this idea, and would like to see 'match' in PHP. At the same
time, is there any need to have the vote right now? The deadline for
PHP 8 feature freeze is July 27 2020.
There were changes to the proposal overnight, which people have not
even had
Heya,
Just following up here, after private convo on why I voted "NO" on this RFC.
My rationale for not wanting the RFC (in its current state) is that I don't
want more procedural constructs in the language.
Specifically, I'm fine with:
match () {
=>
,
=>
,
=>
,
default => ,
Hi Ilija,
1. I was confused by the vote announcement email about what "block statements"
meant - https://github.com/php/php-src/pull/5371#discussion_r415079802
> Thus I have decided to move block expressions to a separate RFC.
This is clarified in https://wiki.php.net/rfc/match_expression#bloc
Hi Dan
> I like this idea, and would like to see 'match' in PHP. At the same
> time, is there any need to have the vote right now? The deadline for
> PHP 8 feature freeze is July 27 2020.
I understand you sentiment. Let me put it this way: I've announced the
first version of this RFC four weeks a
> Am 25.04.2020 um 12:39 schrieb Ilija Tovilo :
>
> Hi internals
>
> I have opened the voting on the match expression RFC. It will end on
> 9th of May, 2020.
> https://wiki.php.net/rfc/match_expression
>
> Here are the last changes:
>
> In the last update I mentioned allowing return values in b
On Sat, 25 Apr 2020 at 11:40, Ilija Tovilo wrote:
>
> Hi internals
>
> I have opened the voting on the match expression RFC. It will end on
> 9th of May, 2020.
> https://wiki.php.net/rfc/match_expression
>
> Here are the last changes:
Hi Ilija,
I like this idea, and would like to see 'match' in
Hi internals
I have opened the voting on the match expression RFC. It will end on
9th of May, 2020.
https://wiki.php.net/rfc/match_expression
Here are the last changes:
In the last update I mentioned allowing return values in blocks.
Unfortunately, we discovered some technical difficulties (memo
28 matches
Mail list logo
