Re: [RFC] [VOTE] Saner numeric strings
| From: | Bob Weinand | 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