Le ven. 11 juil. 2025 à 13:00, Gina P. Banyard <intern...@gpb.moe> a écrit :
> > 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. > That's correct. I feel quite strongly about this: int-to-bool casts should be handled gracefully by the engine seamlessly. Deprecating them will (plan to) break many apps that are just fine, and as Rob wrote (and you also in a gist), casting to (bool) is what many will do, wrongly. This won't improve the language, quite the contrary. About string-to-bool PHP is still that language that allows quickly consuming $_GET['foo'] as whatever it looks like as a string. I suspect tons of codebases rely on this behavior. To me, that's where the costs might outweigh the benefits... 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. > That's an inconsistency favored by the strict-mode hype: people blindly cast (and introduce bugs)... That inconsistency should be fixed the other way around: removing these needless (and dangerous) casts. > 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. > Unfortunate but still to be acknowledged as a likely contribution to making this RFC a high-cost one for userland. > 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. > Deprecating implicit null-ness was (still is) a high impact deprecation, and this one has a higher potential impact IMHO. > And I don't really see what "variants" there are to explore other than a > possible allowance for int-to-bool. > The variant I suggested is to relax the true and false types and make them not-strict when not in strict-mode. Your motivation for the RFC is to make the bool type equivalent to true|false. This can be achieved by relaxing true and false types. Nicolas PS: what about null-forwarding cast operators? (?bool) to let null get through the cast? Just throwing in case it reaches anyone :)
