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
