Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123760
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>
In-Reply-To: <fe435d56-37fa-4b50-b910-bc93687704a2@rwec.co.uk>
Date: Sat, 22 Jun 2024 23:57:24 +0200
Message-ID: <CAPzBOBPfhU+qV8s2+w8gdX7VJhAx=5YFztaQ++VyUr1bBPJiEg@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 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 good=
 word for it, because that's not what it means in normal English.
>
>
> Incidentally, according to the C# docs at https://learn.microsoft.com/en-=
us/dotnet/csharp/language-reference/operators/type-testing-and-cast#as-oper=
ator
>
> > The as operator explicitly converts the result of an expression to a gi=
ven reference or nullable value type. If the conversion isn't possible, the=
 as operator returns null. Unlike a cast expression, the as operator never =
throws an exception.
>
> So it more closely matches my intuition: a statement of just "foo as Bar;=
" would be useless, because it's calculating a value and discarding it, wit=
h 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 statical=
ly analysed type, but in C#, that's all part of the language. In PHP "$foo =
=3D $bar as SomeInterface;" would have no visible effect except in third-pa=
rty 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.

>
>
> --
> Rowan Tommins
> [IMSoP]