Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129029
Feedback-ID: id5114917:Fastmail
Date: Fri, 31 Oct 2025 13:38:44 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
User-Agent: K-9 Mail for Android
In-Reply-To: <CAMU7irKUDV=mtQW-XAoi-WZhNDoE-K4Sv88=2HWUWUcKsJTq4A@mail.gmail.com>
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>
Message-ID: <9BE876E9-93BE-44C5-9C12-8E2C6FF0766F@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 09:05:35 GMT, Alexandre Daubois <alex=2Edaubois+php@gmai=
l=2Ecom> wrote:
>We did some research with Nicolas about deprecating casting null
>instead of proposing a new `(!type)` operator=2E The idea did not make
>it, and we explained why in this new section:
>https://wiki=2Ephp=2Enet/rfc/nullable-not-nullable-cast-operator#alternat=
ive_considereddeprecating_null_casting


This highlights something that's been bugging me about this RFC: you've ca=
lled the "(!type)" syntax a "non-nullable cast", but that's actually the *l=
east significant difference* from existing casts=2E The *most significant d=
ifference* is that it can throw a TypeError for an invalid value=2E=20

In fact I would argue that existing casts don't "accept null" at all - the=
 behaviour of (int)$foo can be adequately described something like this:

1=2E if $foo is already an int, return that
2=2E if $foo is a float, truncate it to an integer
3=2E if $foo is a numeric string, return the integer equivalent
4=2E if $foo begins with a numeric string, return the integer equivalent o=
f that part
5=2E else, return integer zero=20

I may have missed some other cases, but there's no explicit rule for null,=
 it's just falling into the "else" clause at the end=2E=20

You would get the same answer from a hypothetical "cast($foo as int defaul=
t 0)", except that maybe we'd like to remove rule #4=2E

What you are proposing is a new syntax that changes step 5 to "else, throw=
 a TypeError"=2E That might be a useful feature in some cases, but it's not=
hing to do with the title of the RFC=2E



Rowan Tommins
[IMSoP]