On Sat, May 7, 2022 at 1:38 AM Craig Francis <cr...@craigfrancis.co.uk>
wrote:
>
> Not what I'm going for... but anyway, to get an idea of your position, do
> you think the string '15' should be coerced to a number, or should it fatal
> error as well? e.g.
>
> $my_number = round($request->get('my_number'));
>
>
'15' is not an undefined value.
If a program uses the paradigm that null represents the equivalent of
something like `unset($var)`, then the program would not expect coercion to
happen at all if a specific type is demanded, for the same reason that a C
program wouldn't expect an out-of-range memory address to silently evaluate
as an int 0. For programs that use this paradigm, the type system that PHP
*already uses* which has a difference between `?int` and `int`, means that
there is an explicit piece of code noting the exceptions to this rule about
how null is treated.
What exactly would be the purpose of `?int` if this RFC was passed? To pass
the value as null instead of 0? That's it? What about `int|float`? Which
one would it be coerced to? This pretty radically changes how typing itself
would work in existing user programs. What I'm saying is that for such a
radical BC break you need to provide some compelling justification, and I'm
concerned from your replies in this thread and the content of the RFC that
you don't actually understand the extent of a BC-break you're proposing.
Jordan
