Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109591
MIME-Version: 1.0
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
In-Reply-To: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
Date: Sun, 12 Apr 2020 02:58:37 +0200
Message-ID: <CAFPFaM+7Lpe3VVhgAT_yL8d0c-s8cVbvjEJ6Qi8QX40PmopyRQ@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000017310605a30d784f"
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: george.banyard@gmail.com ("G. P. B.")

--00000000000017310605a30d784f
Content-Type: text/plain; charset="UTF-8"

On Sun, 12 Apr 2020 at 02:16, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:

> Hi internals
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>
> Due to the feedback I decided to take the RFC in a slightly different
> direction. The main objections were:
>
> 1. It didn't behave like the traditional switch so it shouldn't use
> the switch keyword
> 2. It didn't fix type coercion
> 3. The RFC was poorly structured
>
> In hindsight I understand why I had a hard time writing the RFC. I
> tried making a case against the switch statement while really not
> addressing the switch statement at all. The new RFC proposes a match
> expression that fixes all the objections raised against the switch
> statement. Additionally, match arms can now contain statement lists
> which allows you to use the match expression anywhere the switch
> statement would have been used previously.
>
> While some people have suggested statement lists aren't necessary I
> don't think it makes sense to raise objections against the switch
> statement without offering an alternative.
>
> I also experimented with pattern matching but decided against it. The
> exact reason is described in the RFC.
>
> I'm now confident this is the right approach. I hope you will be
> happier with this proposal.
>
> Happy Easter!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello Ilija,

I think this is a step in the right direction compared to your previous
attempt.
Your reasoning for not including pattern matching in this RFC also makes
sense.
Moreover, this could be added at a future time when it may make more sense.

One small decision that I personally disagree with is the usage of `=>`
compared to using the colon as the switch statement does.
As for me => means assigning a value to a key which isn't the case here
IMHO.
Also, combining this with less/greater or equal than binary operators makes
for a rather confusing line in my eyes.
E.g. Zend/tests/match/004.phpt in your PR, I don't really see the separation
from where condition and where 'case' starts:

Best regards

George P. Banyard

--00000000000017310605a30d784f--