Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110703
MIME-Version: 1.0
References: <CAPyj-LB7jSiv+7DheaYpEcZXbjeJ9OMsRUTMOofnWbH4LyOQhA@mail.gmail.com>
 <CAPyj-LCV640AZpc=GPb2A+FxqWcSgnzzAH0VVLedCuM0RawmVQ@mail.gmail.com>
 <37f1f8fb-0e1b-cc39-f4b6-6c943a731d49@telia.com> <CAPyj-LAreEydWbK1JcBduQuDtu8r4Bv5a-Oma7mFkr3H2Y3y2A@mail.gmail.com>
 <250b7671-2919-9385-c149-931212397e4b@telia.com> <CAPyj-LDex6tQLp3HmCF6EitOcmBwuVb5ZiGuQsWWN0yUz09XwA@mail.gmail.com>
 <04d86e2d-0815-195a-6111-3034e0ca5918@telia.com> <CANeKSiQC1POTThpADpBHCZWeU8C4YhF3qR+OLEjXq35RKkQyKw@mail.gmail.com>
 <d7c5f55b-9c6f-c04a-15cd-0b66db10b57b@telia.com>
In-Reply-To: <d7c5f55b-9c6f-c04a-15cd-0b66db10b57b@telia.com>
Date: Tue, 23 Jun 2020 11:30:07 +0300
Message-ID: <CANeKSiRhBM3itE0hY80dBDoeLV=-YuYcAFxWavVTqUmrfnpgJA@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Ilija Tovilo <tovilo.ilija@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000081ae1605a8bc2bde"
Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2
From: benas.molis.iml@gmail.com (Benas IML)

--00000000000081ae1605a8bc2bde
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 23, 2020, 11:23 AM Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.co=
m>
wrote:

> Den 2020-06-22 kl. 18:05, skrev Benas IML:
>
> > On Mon, Jun 22, 2020, 6:35 PM Bj=C3=B6rn Larsson <bjorn.x.larsson@telia=
.com>
> > wrote:
> >
> >> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:
> >>
> >>> Hi Bj=C3=B6rn
> >>>
> >>>>> 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 o=
f
> >>> 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 o=
f
> an
> > expression would be a closure:
> >
> > ```
> > $fn =3D 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=C3=B6rn L
>

--00000000000081ae1605a8bc2bde--