Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122706
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMGe=kWWiJYGLG02qxh+2Pe5yTqodhGtAE3LjdAPmkQUw@mail.gmail.com>
 <efbffe5a-f57a-42e4-8e0c-b25ab2c441fc@rwec.co.uk> <CAPzBOBM4b5c=hWgcj6uBgK3Lb65X56T-bhGHVGhma_YnCCJuoQ@mail.gmail.com>
 <CAPzBOBM8dmP5e-N4WXgM+7xbBYx7b=1DyPyJuV5O6QHX2F2s0w@mail.gmail.com>
 <3F78A125-1946-42E2-A4F5-A2B282BE2107@rwec.co.uk> <CAPzBOBPDVE-xtQoFUOXchwNAo_iJTGs=RKcnoq1mOtKF70eeLA@mail.gmail.com>
 <2d7ec203-6e80-445c-94f4-d29ef58743b1@rwec.co.uk>
In-Reply-To: <2d7ec203-6e80-445c-94f4-d29ef58743b1@rwec.co.uk>
Date: Thu, 21 Mar 2024 16:02:22 +0100
Message-ID: <CAPzBOBOqNT17CRiDsw78GH647xM09z4Y4HpSvM55RXoS-BWfKA@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: AS assertions
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 Thu, Mar 21, 2024 at 12:45=E2=80=AFPM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 20/03/2024 23:05, Robert Landers wrote:
>
> In other
> words, I can't think of a case where you'd actually want a Type|null
> and you wouldn't have to check for null anyway.
>
>
> It's not about having to check for null; it's about being able to disting=
uish between "a null value, which was one of the expected types" and "a val=
ue of an unexpected type".
>
> That's a distinction which is made everywhere else in the language: param=
eter types, return types, property types, will all throw an error if you pa=
ss a Foo when a ?Bar was expected, they won't silently coerce it to null.
>
>
>
> If you think about it, in this proposal, you could use it in a match:
>
> // $a is TypeA|TypeB|null
>
> match (true) {
>   $a as ?TypeA =3D> 'a',
>   $a as ?TypeB =3D> 'b',
>   $a =3D=3D=3D null =3D> 'null',
> }
>
>
> That won't work, because match performs a strict comparison, and the as e=
xpression won't return a boolean true. You would have to do this:
>
> match (true) {
>   (bool)($a as ?TypeA) =3D> 'a',
>   (bool)($a as ?TypeB) =3D> 'b',
>   $a =3D=3D=3D null =3D> 'null',
> }
>
> Or this:
>
> match (true) {
>   ($a as ?TypeA) !=3D=3D null =3D> 'a',
>   ($a as ?TypeB) !=3D=3D null =3D> 'b',
>   $a =3D=3D=3D null =3D> 'null',
> }
>
>
> Neither of which is particularly readable. What you're really looking for=
 in that case is an "is" operator:
>
> match (true) {
>   $a is TypeA =3D> 'a',
>   $a is TypeB =3D> 'b',
>   $a =3D=3D=3D null =3D> 'null',
> }
>
> Which in the draft pattern matching RFC Ilija linked to can be abbreviate=
d to:
>
> match ($a) is {
>   TypeA =3D> 'a',
>   TypeB =3D> 'b',
>   null =3D> 'null',
> }
>
>
> Of course, in simple cases, you can use "instanceof" in place of "is" alr=
eady:
>
> match (true) {
>   $a instanceof TypeA =3D> 'a',
>   $a instanceof TypeB =3D> 'b',
>   $a =3D=3D=3D null =3D> 'null',
> }
>
>
>
> Including `null` in that type
> seems to be that you would get null if no other type matches, since
> any variable can be `null`.
>
>
> I can't think of any sense in which "any variable can be null" that is no=
t true of any other type you might put in the union. We could interpret Foo=
|false as meaning "use false as the fallback"; or Foo|int as "use zero as t=
he fallback"; but I don't think that would be sensible.
>
> In other words, the "or null on failure" part is an option to the "as" ex=
pression, it's not part of the type you're checking against. If we only wan=
ted to support "null on failure", we could have a different keyword, like "=
?as":
>
> $bar =3D new Bar;
> $bar as ?Foo; // Error
> $bar ?as Foo; // null (as fallback)
>
> $null =3D null;
> $null as ?Foo; // null (because it's an accepted value)
> $null ?as Foo; // null (as fallback)
>
> A similar suggestion was made in a previous discussion around nullable ca=
sts - to distinguish between (?int)$foo as "cast to nullable int" and (int?=
)$foo as "cast to int, with null on error".
>
>
> Note however that combining ?as with ?? is not enough to support "chosen =
value on failure":
>
> $bar =3D new Bar;
> $bar ?as ?Foo ?? Foo::createDefault(); // creates default object
>
> $null =3D null;
> $null ?as ?Foo ?? Foo::createDefault(); // also creates default object, e=
ven though null is an expected value
>
> That's why my earlier suggestion was to specify the fallback explicitly:
>
> $bar =3D new Bar;
> $bar as ?Foo else null; // null
> $bar as ?Foo else Foo::createDefault(); // default object
>
> $null =3D null;
> $nulll as ?Foo else null; // null
> $null as ?Foo else Foo::createDefault(); // also null, because it's an ac=
cepted value, so the fallback is not evaluated
>
> Probably, it should then be an error if the fallback value doesn't meet t=
he constraint:
>
> $bar =3D new Bar;
> $bar as Foo else null; // error: fallback value null is not of type Foo
> $bar as ?Foo else 42; // error: fallback value 42 is not of type ?Foo
>
>
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]

I don't think you are getting what I am saying.

$a as int|float

would be an int, float, or thrown exception.

$a as int|float|null

would be an int, float, or null.

Robert Landers
Software Engineer
Utrecht NL