Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128973
Precedence: list
MIME-Version: 1.0
References: <CAMU7irLdQg3UVT-SLmyCLWm4Qp81jAcU5uw3Jt=qBpaJCCWWpg@mail.gmail.com>
 <E98C3CE4-3959-4376-A37B-E94E142B3ED6@rwec.co.uk>
In-Reply-To: <E98C3CE4-3959-4376-A37B-E94E142B3ED6@rwec.co.uk>
Date: Mon, 27 Oct 2025 09:03:06 +0100
Message-ID: <CAMU7irLBUAU2t4Den6M8kpPD6wHppM=HphRgjbaiz8j-ZO93OQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.daubois+php@gmail.com (Alexandre Daubois)

Hi Rowan,

> PHP definitely needs a better range of cast operators, and I've been thin=
king for a while about what that should look like. My main concern with thi=
s proposal is that it picks a few specific options and uses syntax in a way=
 that's not easy to extend.

Thank you for your interest! I get your concerns about the extension
of such syntax, but we don't feel that there would be a particular
need of extending this syntax. The syntax does not bring something
really new: the behavior described in the RFC already exists in PHP =E2=80=
=94
we are just making it available at the cast level with explicit null
handling.

> What I mean by that is that there are, roughly, three things that a user =
might want to specify:
>
> 1) What *output types* are desired?
> 2) What *input values* are considered castable?
> 3) What should happen for *invalid* values?
>
> For (1), our current casts allow base scalar types + array. I can definit=
ely see value in allowing nullable types there, but also other complex type=
s, e.g. (string|Widget)$foo could be equivalent to $foo instanceof Widget ?=
 $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 fr=
om the target type.
>
> More importantly, there are a few different things you might *want* to ha=
ppen:
>
> - 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.g. b=
ecause you're *sanitising* untrusted data and want to proceed with the best=
 you can get
> - detect that it *would* fail, e.g. because you're *validating* data.
>
> Throwing exceptions is generally a poor choice for validation or sanitisa=
tion, because you have to either make the user fix one mistake at a time, o=
r add a separate try-catch around every check.
>
> The current RFC adds support for nullable types (1), but only if you *als=
o* want a different set of validation rules (2) *and* a different behaviour=
 if those rules aren't met (3). That's a *useful* combination, but it's not=
 the *only* useful combination. Using the (?type) syntax for that combinati=
on makes it hard to add other combinations in future.

I'm sorry, I think I don't get what you mean. It looks really complex
for something that we would like to keep straightforward. This RFC
doesn't really introduce *new * behavior: these rules already exist in
the engine. Casting with these new operators is indeed stricter than
existing ones and it _may_ look it introduces brand new rules, but it
actually isn't. This strictness comes from implicit casts already done
at function calls.

=E2=80=94 Alexandre Daubois