Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109603
Date: Mon, 13 Apr 2020 11:45:18 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPyj-LAo0tnG=tMJ_ir9SoaYKa1WM1AYCAiyfQ8Xkkx=W4usEw@mail.gmail.com>
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com> <C3F55856-66AF-44F5-8F43-8E41FA8DC6E8@gmail.com> <CAPyj-LBt_Cq+qa49+H3Tav+uepSJ23+TPg_JN5DofGC7y8fnoQ@mail.gmail.com> <6aebe21d-2137-885e-5ee9-99d4f917a7f9@gmail.com> <CAPyj-LAo0tnG=tMJ_ir9SoaYKa1WM1AYCAiyfQ8Xkkx=W4usEw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <5071DCCE-4572-4B1F-A50B-832C5EA74795@gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: rowan.collins@gmail.com (Rowan Tommins)

On 13 April 2020 09:38:10 BST, Ilija Tovilo <tovilo=2Eilija@gmail=2Ecom> wr=
ote:
>It's described in the RFC:
>
>//> Fatal error: Match expressions that utilize the result value can't
>contain statement lists


Thanks, I missed that=2E Reasonably clear, I guess, although I imagine the=
re'll be questions on Stack Overflow asking what a "statement list" is=2E



>> So this would be valid PHP?
>>
>> $x =3D match($y) { 1 =3D> "Hello", 2 =3D> "Goodbye" } echo $y;
>
>No=2E A semicolon is needed=2E Here the semicolon belongs to the
>assignment, not the match=2E=20
=2E=2E=2E
>The only case where expression statement doesn't require a semicolon is
>here:
>
>* Expression statement <- Doesn't require a semicolon
>    * match


Right, so I go back to my earlier point that there are basically two forms=
 of match proposed:

- one where you can use it anywhere an expression is expected, with no sta=
tement blocks
- one which can be used as a standalone statement, which can contain state=
ment blocks, and which doesn't need a trailing semicolon


>> I think needing to add a special case to the grammar is a sign that
>the
>> proposed syntax doesn't fit well with the rest of the language=2E
>
>I find it odd that people keep referring to Rust but apparently have
>no clue how it works=2E This is precisely what they do=2E
>
>https://doc=2Erust-lang=2Eorg/reference/statements=2Ehtml#expression-stat=
ements


I didn't mention Rust, and am fully aware that I don't know how its syntax=
 works=2E What I said was that the proposed syntax doesn't fit into PHP eas=
ily=2E

Two things stand out to me following that link:


Firstly, block expressions are a foundational part of the Rust language, n=
ot a special case used in only one place=2E They're used as the basis for e=
verything from if statements to async blocks, all of which evaluate to a va=
lue=2E That's a really neat design feature, but not something that exists i=
n PHP=2E

It also makes the semicolon rule somewhat more natural: it makes *all* the=
 control flow blocks in Rust feel more natural to developers coming from ot=
her languages=2E It's not an ad hoc rule for one expression, it's a general=
 rule across the language=2E



Secondly, the page you linked calls out an ambiguity caused by omitting th=
e semicolon, which would apply equally in PHP:

match($x) { 1 =3D> ['foo', 'bar'] }
[0];

It then explains the important restriction of only omitting the semicolon =
if the result is void/null rather than a concrete value=2E An equivalent in=
 PHP would be to only allow omitting the semicolon if every arm of the matc=
h is a statement list, further distinguishing the expression and statement =
forms=2E



> I think this RFC
>satisfies your needs=2E It has some extra parts you don't need, and
>that's fine=2E

Just to be clear, that may be fine with you, but if I had a vote, I would =
probably vote no to the current proposal, because I actively dislike the pr=
oposed syntax and semantics of statement blocks=2E They "poison the barrel"=
 for me=2E That's a real shame, because I really like the core of the propo=
sal=2E


Regards,

--=20
Rowan Tommins
[IMSoP]