Hey George, while I agree with your RFC in general, changing the autocast behavior of the empty string is not acceptable for me.
Empty strings often are the output of non-existing things, like default value of a text field in a DB, when reading files not filled with inputs yet etc. It should expose a similar behaviour to all the other falsy values, i.e. null, false, ... The current side effects can be held in mind "ah this won't break if the input is unexpectedly not present, should be safe" while writing code, but finding places where that sort of assumption was made is next to impossible. This should be a major step backwards from the forgiveness of PHP - especially in cases where "shouldn't happen, but the behaviour is nearly always what I expect, and logging will allow me to improve it". I do not want to break everything in production because something happens to return an empty string. I'm aware that it is different from the TypeError behavior of *userland* functions (internal functions do only emit a warning). But internal functions are the important foundation here. This is also internal, the number conversions. Hence I'm voting no on this. Bob > Am 16.07.2020 um 16:18 schrieb G. P. B. <george.bany...@gmail.com>: > > Hello internals, > > I've opened voting for the Saner Numeric strings RFC: > https://wiki.php.net/rfc/saner-numeric-strings > > This will last 2 weeks until the 30th of July > > Best regards > > George P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
