Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109610
User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2
Mime-Version: 1.0
Message-ID: <894804b0-868d-4575-8248-a74e17b3c4fc@www.fastmail.com>
In-Reply-To: 
 <CAEsg9X1=u+ATO8h4nSxOyBstOgBwS1Lhv2bEC+pHv8gbD21A1w@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>
 <5071DCCE-4572-4B1F-A50B-832C5EA74795@gmail.com>
 <CAPyj-LD87_6VcUNLtJbqQatUpBO1fTDb1f_ZgLyAp2fSjqYaLA@mail.gmail.com>
 <e801f32f-7f74-4d3e-4494-5242f213f101@gmail.com>
 <CAEsg9X1=u+ATO8h4nSxOyBstOgBwS1Lhv2bEC+pHv8gbD21A1w@mail.gmail.com>
Date: Mon, 13 Apr 2020 12:31:45 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Apr 13, 2020, at 10:08 AM, David Rodrigues wrote:
> With all the humility of the world and without wanting to be exhaustiv=
e
> about this, my only question is why can't we keep it as a switch, inst=
ead
> of creating a new keyword?

That was the original proposal.  The main issue came down to it being to=
o much different functionality crammed into one bit of syntax, where lot=
s of subtle little context would change the meaning and what you had to =
do.  That's difficult for users, and for the parser.

Fundamentally, this is not a switch statement.  I think it is an error t=
o equate it to or relate it to a switch statement.  It's a more powerful=
, multi-branch version of the ternary operator, and should be conceptual=
ized as such.  And conceptualized that way, I really want it. :-)

Piggybacking off of if makes slightly more sense than off of switch, but=
 it then involves a lot more syntax and a lot more typing, plus the conf=
usion about when it needs a semi-colon and when it doesn't. =20

A new keyword creates a mental separation that is beneficial to users, a=
nd allows it to be implemented with a minimum of syntax and no condition=
al syntax (where certain sigils are needed only in some situations and a=
re an error in others).


> Em seg., 13 de abr. de 2020 =C3=A0s 11:49, Rowan Tommins <rowan.collin=
s@gmail.com>
> escreveu:
>=20
> > On 13/04/2020 12:28, Ilija Tovilo wrote:
> > >> It would be possible for the blocks to return values (though not =
with
> > >> the return keyword).
> > >> [...]
> > > We can't do everything at once.
> >
> > Then why not introduce the match expression first, and add block
> > expressions (as a general concept) later? That way, we don't need al=
l
> > the special restrictions on when to use them, and can work out a
> > consistent set of rules for them which can apply language-wide, rath=
er
> > than being constrained later by decisions we make half-implementing =
them
> > now.
> >
> > The ability to use them with short closure syntax would be very
> > interesting, if the scoping/capture rules could be agreed.

I really feel like this is the best solution.  Multi-line expressions ar=
e not a logical one-off part of match().  They may or may not be a good =
idea for PHP generally, in which case they should be proposed and though=
t through generally.  If they do end up being a good move generally, the=
y'll apply to match naturally just like everywhere else; if not, then th=
ey wouldn't confuse people by being a one-off part of match() and nowher=
e else.

The various discussion about parse logic when the semicolon is there or =
not only highlights that it is not a fully-developed concept.  There's a=
 lot more thought and design that needs to go into multi-line expression=
s that is not in scope for a match expression; embedding statements insi=
de an expression is just weird...

Please, pull that part out.  It's the most (only?) controversial part ri=
ght now.  I suspect (note: no data) that the RFC would pass almost unani=
mously without it (which is good; I want this RFC to pass).  With it, it=
 may pass or not, but it would be a weaker proposal.

At the very least bump it to an secondary add-on vote.

--Larry Garfield