Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129027
Feedback-ID: id5114917:Fastmail
Date: Fri, 31 Oct 2025 13:19:12 +0000
To: internals@lists.php.net
CC: HwapX <hwapx.dev@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
User-Agent: K-9 Mail for Android
In-Reply-To: <0dd89bc1461d0b75c7bae60212466e77@bastelstu.be>
References: <CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com> <E98C3CE4-3959-4376-A37B-E94E142B3ED6@rwec.co.uk> <CAMU7irLBUAU2t4Den6M8kpPD6wHppM=HphRgjbaiz8j-ZO93OQ@mail.gmail.com> <f6d9f646-cc4c-48d6-9017-b7f4966dcab2@rwec.co.uk> <CAPbW5OOg2gYe9z9Gnb_BthRS3XT_Gu1EZD4L64m3GXyOfttnLg@mail.gmail.com> <CAMU7irKUDV=mtQW-XAoi-WZhNDoE-K4Sv88=2HWUWUcKsJTq4A@mail.gmail.com> <0dd89bc1461d0b75c7bae60212466e77@bastelstu.be>
Message-ID: <2904F104-76D8-4DB9-8426-50FCAB0D0C78@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 31 October 2025 12:04:29 GMT, "Tim D=C3=BCsterhus" <tim@bastelstu=2Ebe> =
wrote:
>Given that the proposed semantics matches that of function calls, I share=
 Rowan's suggestion of using =E2=80=9Cfunction-call style=E2=80=9D casts:
>
>    function string_internal(string $input): string { return $input; }
>    function string(mixed $input, bool $passNull =3D false): string {
>        if ($passNull && $input =3D=3D=3D null) return null;
>
>        return string_internal($input);
>    }
>
>    $input =3D 123;
>    $str =3D string($input);
>    var_dump($str);
>
>In fact this is already valid PHP as of now and would allow polyfilling t=
he new operators: https://3v4l=2Eorg/ldvFb and it nicely circumsteps all th=
e backwards compatibility and ecosystem impact as well as the precedence is=
sue=2E The only issue I'm seeing is possible confusion with the existing `s=
trval()` and friends=2E But perhaps this is not relevant in practice=2E


The ability to polyfill is very tempting, but I think this would be a dead=
 end=2E There's no natural way to express nullable types, and no way at all=
 to allow arbitrary union types=2E It would be like having "string_function=
 foo() {}" instead of "function foo(): string {}"

That's why both of my example syntaxes had the type as some sort of *param=
eter*=2E I don't think there's any way around introducing new syntax for th=
at, because you can't "pass a type" to a normal function=2E

There's also no obvious reason why int($foo) and intval($foo) should do di=
fferent things, and neither is inherently "better"=2E

The new int() would cover the "assertion" case (where an invalid value is =
a surprise that should abort processing), and (int) or intval() would cover=
 the "sanitisation" case (where you want to substitute an empty or chosen v=
alue for invalid input), but the names don't tell you which is which=2E

And neither is useful for the "validation" case (where you want to efficie=
ntly test user input)=2E


Rowan Tommins
[IMSoP]