> Am 17.07.2020 um 11:30 schrieb Nikita Popov <nikita....@gmail.com>:
>
> On Fri, Jul 17, 2020 at 11:27 AM Bob Weinand <bobw...@hotmail.com
> <mailto: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 <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
