Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123883
Message-ID: <d9711524-6818-4148-873a-4f27c32a270e@varteg.nz>
Date: Thu, 27 Jun 2024 07:50:10 +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>
 <CAG4FTXz6cH26C5H51VmTGnpFK5XxROFbW4yDzwAw2v1gcQWGgA@mail.gmail.com>
 <CAPzBOBOTSCCKDR4pDocr4xW+oEXJ27YizgPLkn1PGR9nyPU7ww@mail.gmail.com>
 <1E295280-619B-4490-B53C-0899B64F9215@chaz.works>
 <CAPzBOBPSSEmEbPj1zLcfGOOG7voo7YMUO16NjXzpTy7Wfx4ycw@mail.gmail.com>
 <CAPyj-LAM7yPZpcArjHYEG8HhNRR-hA8sgzAjXT7Wf8X4mVgmQA@mail.gmail.com>
 <97a93ae2-5202-47eb-bf51-ec1e976ea765@app.fastmail.com>
 <CAPyj-LC49o=RVXigTrHte8EWSmwxPKqT4tyRGWpGf022PDCk8Q@mail.gmail.com>
 <c72033aa-7d55-4560-95ac-6c81c21cdc43@app.fastmail.com>
 <78D0FFF7-3867-4D71-B0C0-FA23E5121C39@rwec.co.uk>
 <10390963-0c2c-441a-bcce-20a0433948c5@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <10390963-0c2c-441a-bcce-20a0433948c5@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: weedpacket@varteg.nz (Morgan)

On 2024-06-26 09:58, Rob Landers wrote:
> On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
>>
>>
>> It may be questionable to give meaning to the difference in some of 
>> these cases, but different it definitely is.
> 
> True, but I was mainly referring to what you would do after performing 
> an 'is', in which case, you probably wouldn't be using any of those 
> functions, or if you needed to, then why do you need 'is'? Even with the
> 
> $hasFoo = $arr is [?'foo' => string];
> 
> You still have to run array_key_exists() to determine whether the key 
> exists, which means you likely still need to figure out a default value, 
> and null-coalesce is perfect for that ... but then it just points out 
> that it isn't that useful of a check, and that it is inconsistent with 
> itself.
> 
So the issue has nothing to do with this hypothetical infinity of 
unobservable nulls, and comes entirely down to the fact that with this 
pattern a variable may pass
a) because it does not have a key named 'foo', or
b) because it has a key named 'foo' with a string value.

In other words, "this key is optional, but if it is defined it must 
match this pattern".

On its lonesome, that doesn't look very useful, but I expect it would be 
one component of a larger pattern (such as "['bar' => string, ?'foo' => 
string, ...]"). Rather than (near-)duplicate blocks for "it does not 
have the key" and "it has the key and it holds a string", there can be 
one block (which might or might not care about the distinction).