On Mon, 16 May 2022 at 16:06, Andreas Leathley <a.leath...@gmx.net> wrote: > I have created a preliminary > implementation and an RFC for making implicit boolean type coercions > more strict: > > https://wiki.php.net/rfc/stricter_implicit_boolean_coercions > > With this email I'm starting the two week discussion period.
"When discussion ends, and a minimum period of two weeks has passed" Fyi, the two weeks is a minimum, and almost certainly not enough time for subtle BC breaking RFCs like this. > I appreciate your feedback, and if I can improve anything about the RFC I think you should really explicitly list what the changes are in a single table rather than in sentences. > Would you want to know when a value like -375, “false” or NaN > is given to a typed boolean (and coerced to true) in a codebase? Yes. Which is why I always use both PHPStan and Psalm to detect those types of things where those types of bugs are important. Also, strict mode is great. > In one application recently I actually had the string "false" (coming > from a form transmission) being passed to a boolean argument and leading > to true, which definitely was unintended. But "false" is a perfectly sensible thing to pass as a string in an API (as HTTP is a string based protocol). As is 'faux' if your API is used by French speaking programmers. You need an layer of code that converts from strings to the precise types your API needs, rather than just passing values straight through. > if it mainly reveals bugs in applications, couldn't that > be enough of a reason in favor of it? Although this change would probably detect some bugs, it's not at all obvious that the amount of pain would be worth it. A lot of applications out there aren't being constantly developed. Instead they are in maintenance mode, where there isn't a programmer dedicated to constantly work on it. There would be lots of function calls to check, and some of them would need code to be modified to maintain the existing behaviour. And all of that would seem to be subtle work, prone to mistakes. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
