Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129022
Precedence: list
MIME-Version: 1.0
Date: Fri, 31 Oct 2025 13:04:29 +0100
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: HwapX <hwapx.dev@gmail.com>, internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Nullable and non-nullable cast operators
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: <0dd89bc1461d0b75c7bae60212466e77@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Thank you for the RFC. I agree that having functionality to do type 
conversions in a safer and/or more succinct way is useful. However

Am 2025-10-31 10:05, schrieb Alexandre Daubois:
> This is fortunately not a blocker to this RFC, as this would address
> an orthogonal problem. As you said, we have plenty of time before 8.6!

I share Rowan's concerns about the proposed syntax. And I disagree that 
that the proposed Future Scope is not a blocker for this RFC. If we 
decide to introduce new syntax for this type of casts, then the “Future 
Scope” might also be interested in new syntax.

One big problem with the current syntax, that is hinted at in the 
backwards compatibility section is that PHP does not have a generic 
“type cast” syntax, but instead requires a separate token for each 
possible cast. This means:

1. It has quite a big impact on the ecosystem, since each tool working 
with the tokenizer needs to learn about the new tokens. Similarly, they 
also need to learn about new AST nodes to even make sense of the code. 
In fact the “RFC Impact” section from the suggested RFC template 
(https://wiki.php.net/rfc/template#rfc_impact) is completely missing 
from your RFC. Every RFC that introduces syntax has a significant impact 
on all kinds of tooling and also for users learning the language.

2. “no backward compatibility issues:” as an absolute statement is 
incorrect, as you acknowledge yourself right below: “The syntax (!type) 
is technically correct”. It is true that this is exceedingly unlikely to 
affect existing code, but it is wrong to say that there are no BC 
issues. The RFC template specifically states “Please include all 
breaking changes, no matter how minor they might appear.”

With regard to reusing the type cast syntax, one issue I'm already 
having with the existing casts is that I don't have a good intuition 
about the precedence of the casting operators and the accepted PER-CS 
code style does not help there:

     $a = "1";
     $b = "2";
     $result = (int) $a . $b; // what is $result?

Given that the proposed semantics matches that of function calls, I 
share Rowan's suggestion of using “function-call style” casts:

     function string_internal(string $input): string { return $input; }
     function string(mixed $input, bool $passNull = false): string {
         if ($passNull && $input === null) return null;

         return string_internal($input);
     }

     $input = 123;
     $str = string($input);
     var_dump($str);

In fact this is already valid PHP as of now and would allow polyfilling 
the new operators: https://3v4l.org/ldvFb and it nicely circumsteps all 
the backwards compatibility and ecosystem impact as well as the 
precedence issue. The only issue I'm seeing is possible confusion with 
the existing `strval()` and friends. But perhaps this is not relevant in 
practice.

Best regards
Tim Düsterhus