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
