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: >> No offense, but this feels like it was written by someone who doesn’t use >> non-strict mode very often. > > As yes, saying this to me, someone that is known to have said on stage, > multiple times, during talks that > > The strict_types declare was a mistake. > Something I even reiterated 7 weeks ago at a Drupal conference. [1] > It would be nice that you don't make assumption about how I write PHP code, > as I use weak and strict mode extensively while being annoyed with both modes > constantly. > Moreover, even if one uses strict mode one must still know how weak mode > behaves as closures/callables do not follow the typing mode in which they > have been declared.
Hey Gina, As mentioned, my intent wasn’t to offend. My goal was to tell you how it read, from my perspective, whether you intended it to or not. As in someone trying to force everyone using weak mode to use strict mode. I’m really sorry that it came across that way, though. > >> The rules around coercion are pretty simple and well documented. > > Considering I have given *multiple* talks about PHP's type system and type > coercions rules, many people do *not* find them simple or intuitive and get > bitten by them constantly. That is a fair point. I’ve seen the same confusion among juniors (and sometimes seniors!) over the years. My sense, though, is that some confusion is less about PHP’s type system itself and more about the unique way PHP handles requests compared to other languages. In most languages, frameworks insulate you from the raw request data and make explicit choices about parsing and typing. In PHP, by contrast, you often get the raw bytes, and it is up to you (or your framework, hopefully) to massage that into proper types—which can lead to surprising behaviours if you’re not careful. I think sometimes people bring expectations from other ecosystems (where, say, the string “false” might have special meaning) and are surprised when PHP treats “false” like any other non-empty string. Maybe that mismatch is the root of a lot of frustrations? Curious if you see it the same way, or if there is something more fundamental in PHP’s type rules you think causes the confusion? > >> 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. 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. > >>> Type juggling of strings to bool is similarly error-prone. The strings "" >>> and "0" are converted to false, but "false", " ", and other strings which >>> an (int) cast converts to 0 are coerced to true. >> >> If I understand correctly, you are saying it is weird why the bytes 66 61 6C >> 73 65 are “true” and 30 is a special case, but not 20? If I remember my >> history correctly, 30 is special-cased because forms used to send “0” on >> checkboxes (if it sent it at all; it changed from decade to decade). > > I know the reason why we coerce the string "0" to false. > But it is very atypical compared to every other programming language, so yes > it is "weird". I will 100% agree with you about "0" being *false*. It was a handy shortcut 20 years ago, but these days it creates more confusion than it solves. > >> I don’t see the benefit of removing this implicit coercion. > > The statement is noted. > > > Regards, > > Gina P. Banyard > > [1] https://youtu.be/85fgBcV3BuM?t=2832 — Rob
