Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123716
Message-ID: <02ee8831-43a0-4857-886e-7f54fb42a99d@varteg.nz>
Date: Fri, 21 Jun 2024 10:09:16 +1200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: internals@lists.php.net
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: weedpacket@varteg.nz (Morgan)

On 2024-06-21 05:38, Larry Garfield wrote:
> Hello, peoples.
> 
> To that end, we're looking for *very high level* feedback on this RFC:
> 
> https://wiki.php.net/rfc/pattern-matching
> 

As I started reading I starting thinking of "whatabouts" based on my 
experience with pattern matching in other languages, and as I skimmed 
the RFC I found each of them being addressed. I'm looking forward to this.



If you want my feedback about match() "is" placement, I can see the 
benefits of both, and they don't look mutually exclusive, since the "is" 
effectively just distributes over the branches to produce the inline 
alternative; with that interpretation it's just an error to have "is" in 
the top position and something other than a type pattern in any branch 
because it would be equivalent to "is <not a type pattern>".

I suspect the case where one is matching against a list of types will 
turn out to be quite common, so if "match ($somevar) is {" weren't 
implemented there'd soon be people asking for something equivalent to 
save them typing "is" over and over.

One thing to note is that if "is" were to be in the top position, it 
means every branch has to be a type pattern, which means instead of 
"default" the catch-all branch would be "mixed". (That's a question: 
won't the branches of "match($var)is{" need to range over every possible 
type?)



One tiny note about BC breakage:

 >  If the as keyword is adopted as well, that will also be a new global 
keyword.

"as" is already a global keyword (as in "foreach($arr as $e)"). So 
that's not such a problem after all.