Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128953
Feedback-ID: id5114917:Fastmail
Date: Fri, 24 Oct 2025 14:58:30 +0100
To: PHP internals list <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: <CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com>
References: <CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com>
Message-ID: <E98C3CE4-3959-4376-A37B-E94E142B3ED6@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 24 October 2025 08:07:02 BST, Alexandre Daubois <alex=2Edaubois+php@gmai=
l=2Ecom> wrote:
>Hi everyone,
>
>Nicolas Grekas and I would like to propose this new RFC to the
>discussion=2E This proposes to introduce two new cast operators to the
>language: `(?type)` and `(!type)`=2E
>
>Please find the details here:
>https://wiki=2Ephp=2Enet/rfc/nullable-not-nullable-cast-operator


Hi both, and thanks for the RFC=2E

PHP definitely needs a better range of cast operators, and I've been think=
ing for a while about what that should look like=2E My main concern with th=
is proposal is that it picks a few specific options and uses syntax in a wa=
y that's not easy to extend=2E

What I mean by that is that there are, roughly, three things that a user m=
ight want to specify:

1) What *output types* are desired?
2) What *input values* are considered castable?
3) What should happen for *invalid* values?=20

For (1), our current casts allow base scalar types + array=2E I can defini=
tely see value in allowing nullable types there, but also other complex typ=
es, e=2Eg=2E (string|Widget)$foo could be equivalent to $foo instanceof Wid=
get ? $foo : (string)$foo

For (2) and (3), you could say our current casts accept anything, but you =
could argue that they replace invalid values with a fixed "empty" value fro=
m the target type=2E

More importantly, there are a few different things you might *want* to hap=
pen:

- throw an exception, because you expect the cast to succeed, and want to =
abort if it doesn't
- fill with null, or with some default value from the target type, e=2Eg=
=2E because you're *sanitising* untrusted data and want to proceed with the=
 best you can get
- detect that it *would* fail, e=2Eg=2E because you're *validating* data=
=2E

Throwing exceptions is generally a poor choice for validation or sanitisat=
ion, because you have to either make the user fix one mistake at a time, or=
 add a separate try-catch around every check=2E

The current RFC adds support for nullable types (1), but only if you *also=
* want a different set of validation rules (2) *and* a different behaviour =
if those rules aren't met (3)=2E That's a *useful* combination, but it's no=
t the *only* useful combination=2E Using the (?type) syntax for that combin=
ation makes it hard to add other combinations in future=2E


Rowan Tommins
[IMSoP]