On Fri, Jul 17, 2020 at 11:27 AM Bob Weinand <bobw...@hotmail.com> wrote:
> 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. > Can you give a code example for an undesirable behavior change? I don't think this proposal changes anything about the handling of empty strings. Empty strings are already considered non-numeric, and as such already result in TypeErrors (e.g. https://3v4l.org/WVfeg). Nikita > > 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 > >
