Re: [RFC] Deprecate type juggling to and from bool type within the function type juggling context

On Tuesday, 3 June 2025 at 18:44, Rob Landers <rob@bottled.codes> wrote: > On Tue, Jun 3, 2025, at 18:19, Gina P. Banyard wrote: > >> On Monday, 2 June 2025 at 22:05, Rob Landers <rob@bottled.codes> wrote: >> >>> Further, this makes a ton of shorthand nearly impossible — the manual casting to bool >>> in strict mode is one of the most annoying casts someone has to do (and people screw up order of >>> operations all the time leading to subtle bugs worse than coercion). Bringing this into all of php >>> is probably not a good idea. >> >> It would have been nice to showcase some of these shorthands rather than hiding them behind >> some sort of mystic as a counterargument. >> I really would like to know in which cases you use non-boolean values as argument to >> boolean parameters. >> People creating more subtle and worse bugs due to arbitrary casting is precisely why I want >> to unify the typing modes, so it's good to know that we think somewhat the same. > > // From a real codebase (sanitized): > $shouldStop = (bool)($result = $service->doSomething($input)) && > $result->isError(); > > This pattern comes up a lot in strict mode: you have to be extra careful with casts and > parentheses, or you can end up with subtle bugs like accidentally always returning true/false, or > masking null/error values. In looser modes, this just “worked”, but strictness can make it > surprisingly easy to trip up. I don't get it, you don't need a bool cast here: https://3v4l.org/J4BWi Even with strict_types: https://3v4l.org/dhnpc > In my experience, a lot of “non-boolean to boolean” cases are legacy patterns or > integrations, but sometimes we’re dealing with values that can be “falsy” in multiple ways > (empty array, 0, '', etc.). Sometimes we’re adapting legacy code or writing wrappers > that need to accept a wide range of inputs. > > The problem, in my view, is that forcing strictness everywhere makes the simple, idiomatic code > that worked in PHP for years much more verbose; and potentially more error-prone if the developer > isn’t careful with casts or operator precedence. This proposal has no intention of changing the type juggling behaviour of the logical binary operators (and unary ! op) so you shouldn't ever *need* to use both an operator and a cast (even now with strict_types on). Best regards, Gina P. Banyard