Re: [RFC] [VOTE] Saner numeric strings

From: Date: Fri, 17 Jul 2020 09:39:57 +0000
Subject: Re: [RFC] [VOTE] Saner numeric strings
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-111065@lists.php.net to get a copy of this message
> Am 17.07.2020 um 11:30 schrieb Nikita Popov <nikita.ppv@gmail.com>: > > On Fri, Jul 17, 2020 at 11:27 AM Bob Weinand <bobwei9@hotmail.com > <mailto:bobwei9@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 > <https://3v4l.org/WVfeg>). > > Nikita Apparently I tested the wrong functions. Was having a look at pow() which accepts a number. Sigh. Then it's the fault of pow() and pow() should be probably fixed… But as an example, I was storing values as a pipe delimited string of counters in the db - added a new value and forgot to update the old records. Old records looking like "1|27|37|". Doing an list($a, $b, $c, $d) = explode("|", $input); worked fine, but $d was, well, an empty string. Quickly found the reason in the logs, updated the db, but our end users didn't notice anything. Bob

« previous php.internals (#111065) next »