Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123761
Precedence: bulk
MIME-Version: 1.0
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <978b7177-8a22-41c0-94ce-d5539a2468c5@app.fastmail.com> <be98ada8-a0a5-4c7a-8dc4-a3f6becf861a@app.fastmail.com>
 <ce1de6a5-55ec-4850-8acf-ac5ba1ba95fe@rwec.co.uk> <CAPzBOBOwAbR=3cbyQxgYbnBEGcoJbkReOYVTsrd0ojBbZbf=ng@mail.gmail.com>
 <fe435d56-37fa-4b50-b910-bc93687704a2@rwec.co.uk> <CAPzBOBPfhU+qV8s2+w8gdX7VJhAx=5YFztaQ++VyUr1bBPJiEg@mail.gmail.com>
In-Reply-To: <CAPzBOBPfhU+qV8s2+w8gdX7VJhAx=5YFztaQ++VyUr1bBPJiEg@mail.gmail.com>
Date: Sun, 23 Jun 2024 00:05:18 +0200
Message-ID: <CAPzBOBPPDGxu4WDsqhYESWrhO_2e9kDmgr8tpfR14kqdXoTXLQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Sat, Jun 22, 2024 at 11:57=E2=80=AFPM Robert Landers
<landers.robert@gmail.com> wrote:
>
> On Sat, Jun 22, 2024 at 10:53=E2=80=AFPM Rowan Tommins [IMSoP]
> <imsop.php@rwec.co.uk> wrote:
> >
> > On 22/06/2024 19:34, Robert Landers wrote:
> >
> > I've brought this up before, but I mostly see "as" being useful for
> > static analysis. That's what I've mostly used it for C#, anyway.
> > Logically, you know the type, but due to one-thing-or-another you
> > can't "prove" the type is that type (such as foreach-arrays or dealing
> > with results from user-code callbacks in library code). I want to be
> > able to say "this is an int or else."
> >
> >
> > I absolutely see the use case for that; I just don't think "as" is a go=
od word for it, because that's not what it means in normal English.
> >
> >
> > Incidentally, according to the C# docs at https://learn.microsoft.com/e=
n-us/dotnet/csharp/language-reference/operators/type-testing-and-cast#as-op=
erator
> >
> > > The as operator explicitly converts the result of an expression to a =
given reference or nullable value type. If the conversion isn't possible, t=
he as operator returns null. Unlike a cast expression, the as operator neve=
r throws an exception.
> >
> > So it more closely matches my intuition: a statement of just "foo as Ba=
r;" would be useless, because it's calculating a value and discarding it, w=
ith no side effects.
>
> In general, you assign the result of the operation so that the output
> is useful. Here's how that might look in PHP with the C# rules:
>
> function foo(BarInterface $bar) {
>   $baz =3D $bar as Baz;
>   $baz?->thing();
>   $bar->otherThing();
> }
>
> With "is" then it looks a little more wonky but isn't far from the
> current instanceof method:
>
> function foo(BarInterface $bar) {
>   if ( $bar is Baz ) $bar->thing();
>   $bar->otherThing();
> }
>
> With fibers/async, "as" is actually more important than "is" (at least
> as far as crashing goes):
>
> class Foo {
>   public BarInterface $bar;
>
>   public function doStuff() {
>     $baz =3D $this->bar as Baz;
>     // some stuff with $baz
>     callComplexThing(); // suspends current fiber,
>     // $this->bar is no longer the same object
>     // or concrete type when we return
>     $baz->something();
>   }
> }
>
> If we were to do an "is" check on the first line, by the time the
> fiber is resumed, we've got a completely different type on our hands
> and it would crash. Maybe that is desirable, maybe not, but we know
> that we have a reference of the type we want and it won't be changed
> under us by using "as."
>
> > As you say, the conversion might not be of the value, but of the static=
ally analysed type, but in C#, that's all part of the language. In PHP "$fo=
o =3D $bar as SomeInterface;" would have no visible effect except in third-=
party tooling, where it can already be written "/** @var SomeInterface $foo=
 */ $foo =3D $bar;"
>
> Hopefully my examples show how it can be useful (at least when it
> returns null if it is the wrong type). When it gives a TypeError or
> something, it becomes far less useful -- at least for the sake of
> conciseness. However, it becomes far more useful to dealing with
> scalar casts:
>
> function foo(int $type) {}
>
> foo(123.456 as int); // crashes
> foo(null as int); // crashes
>
> But even if we did return null, those would crash unless foo() took
> int|null, which may or may not be what you want ...
>
> With it always being an error if it doesn't match, it's really not
> that useful, as you point out.

Side-note: this is why my original proposal had two modes (based on
the existence of null in the typecheck):

foo(123.456 as int);

would crash due to being unable to cleanly cast to int.

foo(123.456 as int|null);

would crash from passing null (since literally everything can be
casted to null and it can't be casted to an int).

>
> >
> >
> > --
> > Rowan Tommins
> > [IMSoP]