Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123805
Feedback-ID: id5114917:Fastmail
Date: Tue, 25 Jun 2024 08:22:51 +0100
To: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
User-Agent: K-9 Mail for Android
In-Reply-To: <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com> <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
Message-ID: <B7C88F1B-BCA9-4E3D-AC0E-5E32E6011ACF@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 25 June 2024 00:31:56 BST, Larry Garfield <larry@garfieldtech=2Ecom> wr=
ote:
>
>* There's not been much discussion of range patterns=2E  Anyone want to w=
eigh in on those?


I didn't even notice them until someone else mentioned some detail of the =
syntax=2E

Like regex patterns and the generic-like array syntax, they look really us=
eful, but also like something that should be standardised across the langua=
ge, and not just snuck in to patterns=2E

I don't mean we have to implement "foreach(1=2E=2E10 as $b)" at the same t=
ime as "$a is 1=2E=2E10", necessarily, but we're going to hate ourselves if=
 we rush in a range syntax for patterns then realise we *can't* reuse it el=
sewhere for some reason=2E


My personal preference would be to keep the first RFC as focused as possib=
le, so that we have time to discuss everything in it=2E Additional patterns=
 could be an immediate follow-up RFC within the same release cycle=2E

So I think that means the first RFC covering:

- The concept of patterns
- The "is" keyword
- match integration
- Variable binding=20
- Variables in expressions (as you say, we need to at least discuss the sy=
ntax for these at the same time as variable binding)
- Type patterns
- Literal patterns=20
- Class constant patterns=20
- Compound patterns (unions and intersections)
- Array destructuring-like patterns
- Object property patterns (these feel essential, but notably are the only=
 thing on this list not based on an existing syntax)

=2E
That's still a big list of things to discuss=2E

Once we have the concept of patterns in the language, there's plenty of sc=
ope for adding more of them, and more places to use them, but let's not be =
too hasty in throwing every shiny feature in at once=2E



>* No one has really weighed in on nested patterns for captured variables=
=2E  Any thoughts there?

They feel almost-essential to me, because it feels odd to have to choose t=
o *either* specify an element *or* capture it, as in "$foo is [int, string]=
" vs "$foo is [$a, $b]"=2E On the other hand, in their full glory they allo=
w for some extremely complex patterns, and that might put some people off=
=2E

As with variables in patterns, we probably need to at least consider *how*=
 to write them before committing to the overall syntax=2E e=2Eg=2E my earli=
er suggestion of "$foo=3D" for binding fits very naturally with "$foo=3Dint=
"; but if we had ">>$foo" it would feel more natural to write "int>>$foo", =
and would that order be better or worse?=20

Regards,
Rowan Tommins
[IMSoP]