On Monday, 30 June 2025 at 10:26, Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote:
> Hi Gina > > Thanks for experimenting with this on > https://github.com/symfony/symfony/pull/60890/files > > It's good to see that fitting this RFC requires a relatively small number of > lines to change even on a codebase like Symfony. We're not at 100% but still > nice. > > Yet, it IS a big bang in terms of deprecations to fix that this will trigger. > Their number is super high, because these boolean conversions happen on > hotpath / in loops. > > This reminds me of the mandatory "?" for arguments with null defaults: the > change made sense from a language design PoV, but the impact was, and still > is very high. It was and still is a very costly deprecation for the > community, and it's not over yet. That made me say at conferences that this > was maybe not a good idea... > > Looking at the diff above, I think I can draw two sets of changes: > 1. the ones that patch a cast-to-bool > 2. the ones that patch a cast-from-bool > > The latter, cast-from-bool, I think they're all useful improvements. While > most likely harmless in all the specific cases of the PR, doing e.g. an > strpos() on false feels hardly legit. I'm therefore sympathetic to making > these changes. > > For cast-to-bool, I'm WAY less convinced. From the PR above, explicit casts > like "return (bool) preg_match(...)" on a method that returns a "bool" or > "(bool) ($this->loggedErrors & $type)" are a clear downgrade: it makes the > typing PHP just more verbose without any real benefit. That doesn't look > worth asking the whole ecosystem to fix those deprecations. It is especially > hard to see this as an improvement when comparing to using the same > expressions with e.g. the "if ()" operator, which doesn't need the explicit > cast (and shouldn't of course). Every cast-to-bool example you are providing are int-to-bool coercions, not string nor float casts type. Especially that even within SFs test suite, various cases of string-to-bool casts seems to be highlighting some sort of bug in the test suite. Moreover, the fixes for the bitwise & operator are following the styles from surrounding functions that _already_ do that, and I was slightly confused about the inconsistencies. The preg_match() API is just unfortunate that it returns a boolean value as integers rather than booleans, as it uses a false return to communicate it emitted a warning instead of null. Improving this API, is a very orthogonal problem to this, that we probably should be doing anyway (e.g. see if we can promote the warnings to exceptions). And I could be convinced to carve out an exception for int-to-bool, however that retains some complexity remembering PHP's type juggling rules, or have it as a secondary vote. > In the RFC, you write that its motivation is to allow making the bool type > equivalent to the true|false union. To do so you propose to make the bool > type always behave like in "strict" mode. > > Personally, I'm moot about the motivation. I understand it, but it looks > inappropriate to push deprecations from this somewhat (IMHO) theoretical > angle. The added friction would need way stronger arguments to be justified > IMHO. > > Would it be possible to trigger the deprecation only in the cast-from-bool > direction, and accept casts-to-bool as seamlessly as there are now? If yes, > then would it also be possible to make the true and false types have the same > behavior (aka non-strict in casts-to-bool direction - when not in strict mode > of course)? If yes to both questions, then that'd look like a better outcome > that'd still allow fulfilling your goal, while providing maximum value to the > community. > > As is, the cost/benefit ratio doesn't make this RFC look worth it to me. As said above, it is even possible to only warn on string- and float-to-bool and not on int-to-bool coercions. But I still think theoretical angles are important, because allowing edge cases always adds complexity that has causes us countless headaches in the past. > Last but not least, I'm not sure it's a good idea to rush this into 8.5. This > is a high-impact change. We should give some time to the discussion, > understand the impact and explore variants. Merging this in 8.6 would also > give a few more months for open-source projects to adapt to the change (since > many do run their CI with the master branch of PHP to spot changes as early > as possible.) I'm not exactly certain I buy the argument that delaying this deprecation is worthwhile, especially as I don't really think is as high impact as it is made out to be. And I don't really see what "variants" there are to explore other than a possible allowance for int-to-bool. As we are trading time for users to fix their code upcoming to PHP 9 for open source libraries where many use strict_types and as such are not affected by this change. Best regards, Gina P. Banyard
