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