Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123898
Precedence: bulk
MIME-Version: 1.0
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> <d9711524-6818-4148-873a-4f27c32a270e@varteg.nz>
 <8498ecf7-f431-4d68-aaf1-dc4cfb00241b@app.fastmail.com>
In-Reply-To: <8498ecf7-f431-4d68-aaf1-dc4cfb00241b@app.fastmail.com>
Date: Wed, 26 Jun 2024 23:42:39 +0200
Message-ID: <CAPyj-LDD01-u9TT6CNvvH1-9qnxM9WxMqHzWFmY11Ys6SxF2Aw@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Rob

On Wed, Jun 26, 2024 at 10:36=E2=80=AFPM Rob Landers <rob@bottled.codes> wr=
ote:
>
>> On Wed, Jun 26, 2024, at 21:50, Morgan wrote:
>>
>> 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".
>
> Seriously, write out using it both ways. I asked in the beginning for som=
eone to give a realistic example showing a practical difference in the fina=
l implementation and I haven=E2=80=99t seen one. I will gracefully eat my h=
at. The main issue is that key-existence-check is logically inconsistent wi=
th itself (if you say the key shouldn=E2=80=99t exist or be a string, you=
=E2=80=99d be surprised to get null from that key!)

function test($value) {
    if ($value is ['foo' =3D> ?string]) {
        $foo =3D $value['foo'];
    }
}
test([]);

With your approach, the example above would emit a warning, even
though the context within test() doesn't look like it should. If
?string means that the index might or might not exist, all code that
accesses them must check for existence, even when not needing to
handle null itself. That doesn't seem desirable to me.

I also think the issue goes further. If anything|null means that the
offset might not exist, does that include mixed? That makes ['foo' =3D>
mixed] essentially useless.

Ilija