Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129117
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 06 Nov 2025 10:17:32 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <5ee6282f-3775-4408-b6e1-44166fbd8d1c@app.fastmail.com>
In-Reply-To: <2529fb76-6b6c-4304-98b9-1ffa034e1e1f@rwec.co.uk>
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>
 <2529fb76-6b6c-4304-98b9-1ffa034e1e1f@rwec.co.uk>
Subject: Re: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Nov 5, 2025, at 4:48 PM, Rowan Tommins [IMSoP] wrote:
> 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=20
> 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=20
> TypeError.
> 2) Certain values, such as "123foo" are considered numeric by one, but=20
> not by the other.
>
> That's it. There's no need to mention null specifically, it's just one=20
> of many non-numeric values.
>
> In fact, people might forget to mention point 2, because the=C2=A0diff=
erence=20
> between "always returns an integer" and "may cause your entire program=20
> to exit if fed unvalidated input" is far more important.
>
> So, if you want a name, I suggest something to do with "throw" or "err=
or".
>
>
> But the problem I see with the RFC is deeper than that: there's no=20
> actual discussion of *why* throwing a TypeError is better, or *when*=20
> this completely new form of cast would be used.
>
> As I've tried to argue in previous messages, exception-handling is *no=
t*=20
> convenient for tasks like handling user input. It is maybe useful for=20
> deeper code, where you expect the value to already be validated. So I=20
> think we should be looking at more than one type of new cast; or at=20
> 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=20
> maybe null output.
>
> But in the proposal, using the new operator will *crash my application=
*=20
> for values where the other returned zero, and even for values where th=
e=20
> other returned non-zero integers.
>
> If that part of the proposal goes to a vote as currently written, I wi=
ll=20
> vote No.
>
>
> --=20
> Rowan Tommins
> [IMSoP]


I very much appreciate the goal here, but at the same time I share Rowan=
 and other's concerns that it's too one-off and non-obvious.

The general case here is "I have a variable of type X, and I want to los=
slessly convert it t type Y if that's possible, and do this other thing =
if not."  Where "the other thing" could be "return null", "Warning", "Ex=
ception", "default value", etc. =20

This is in contrast to the current casting logic, which allows a lossy c=
onversion with no communication that a loss has happened.

Lossy and lossless conversion are sufficiently different that the syntax=
 should not be so similar. =20

My first thought is some kind of language construct pseudo-function, lik=
e:

cast($var, int); // Weak mode rules conversion to int, or error
cast($var, ?int); // Weak mode rules conversion to int, allowing null, o=
r error
cast($var, int|string|null); // Weak mode rules conversion to int if pos=
sible, string if not, allow null, or error

(This may or may not be ideal.)

But at this point, it feels an awful lot like filter_var() (https://www.=
php.net/filter_var).

And of course there's the question of how to signal an incompatibility. =
 Returning null defeats the purpose of allowing null, an exception is to=
o heavy and inappropriate, and... we have nothing else.

I feel compelled to mention my error handling proposal from earlier this=
 year: https://externals.io/message/127188

I'm in favor of better type conversion tools that follow the same weak-r=
ules as functions.  But I agree that just sticking a ? in the existing s=
yntax and calling it a day is not the right approach, even if it feels e=
asy at first blush.

--Larry Garfield