Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129097
Feedback-ID: id5114917:Fastmail
Message-ID: <2529fb76-6b6c-4304-98b9-1ffa034e1e1f@rwec.co.uk>
Date: Wed, 5 Nov 2025 22:48:06 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
Content-Language: en-GB
To: internals@lists.php.net
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>
 <9BE876E9-93BE-44C5-9C12-8E2C6FF0766F@rwec.co.uk>
 <CAMU7irLKxjiwgssh5BET1Gy1KSwDrN8ipyu5G4EjCHCL_5WLuw@mail.gmail.com>
In-Reply-To: <CAMU7irLKxjiwgssh5BET1Gy1KSwDrN8ipyu5G4EjCHCL_5WLuw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 05/11/2025 08:38, Alexandre Daubois wrote:
> What we propose is to align these new operators to already existing
> rules applied to function arguments. This is, indeed, stricter than
> current cast operators. But I wouldn't say it has*nothing to do* with
> the title of the RFC.
> Maybe it's not perfectly accurate. If the naming is a problem and
> should be changed, I'd be happy to hear suggestions and update
> accordingly with a better name.

Let's imagine how someone would describe these two expressions if this 
RFC passed:

(int)$foo
(!int)$foo

Here are the differences I see:

1) The first casts any non-numeric input to zero; the second throws 
TypeError.
2) Certain values, such as "123foo" are considered numeric by one, but 
not by the other.

That's it. There's no need to mention null specifically, it's just one 
of many non-numeric values.

In fact, people might forget to mention point 2, because the difference 
between "always returns an integer" and "may cause your entire program 
to exit if fed unvalidated input" is far more important.

So, if you want a name, I suggest something to do with "throw" or "error".


But the problem I see with the RFC is deeper than that: there's no 
actual discussion of *why* throwing a TypeError is better, or *when* 
this completely new form of cast would be used.

As I've tried to argue in previous messages, exception-handling is *not* 
convenient for tasks like handling user input. It is maybe useful for 
deeper code, where you expect the value to already be validated. So I 
think we should be looking at more than one type of new cast; or at 
least a choice of syntax that anticipates that.


As for the other part of the RFC, looking at these two expressions:

(int)$foo
(?int)$foo

I would expect the *only* differences to be to do with null input, and 
maybe null output.

But in the proposal, using the new operator will *crash my application* 
for values where the other returned zero, and even for values where the 
other returned non-zero integers.

If that part of the proposal goes to a vote as currently written, I will 
vote No.


-- 
Rowan Tommins
[IMSoP]