[RFC] [VOTE] Saner numeric strings

Hey George,

I really like this specific bit of the proposal:

And the various cases which currently emit an E_WARNING will be
promoted to TypeErrors.

I really do not like these particular horrible behaviors of the language
(huge "yikes" for PHP being so broken):

• "123" == "123 " - do not want - already bad enough that leading
  whitespace is ignored here, and already caused some security issues on my
  end some years ago
• is_numeric("123 ") === true - is_numeric() should probably be
  soft-deprecated and replaced with something stricter, instead of expanding
  this too...

I don't really care about `declare(strict_types=0), since I don't use it
anymore, nor plan to use it anymore in any foreseeable future, but the two
points above really feel wrong, and I'm conflicted about what to vote.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Hey Marco,

I do agree that accepting trailing whitespace may be considered suboptimal
but as leading whitespaces don't even emit an E_NOTICE it is impossible to
drop this "feature".
Therefore I went for the next best thing which makes it IMHO sane, i.e.
accepting trailing whitespaces everywhere.

One way to improve the comparison case could be by adding an "eq" op like
PERL has which always do a string comparison,
basically equivalent to (string) $a === (string) $b as in PERL == always
does a numerical comparison, which is not the case in PHP as it tries to be
"smart".

To address the second point, deprecating is_numeric seems out of scope for
this RFC and could be a future scope.

Hope this clarifies some of the reasoning.

Best regards

George P. Banyard

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.banyard@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

--

To unsubscribe, visit: https://www.php.net/unsub.php

On Wed, Jul 22, 2020 at 4:21 PM Christian Schneider cschneid@cschneid.com
wrote:

but not to arithmetic operators like 42 + "" because that doesn't
currently trigger E_WARNING AFAIK.

It does produce warning since PHP 7.1 : https://3v4l.org/4CV1E

--
Best regards,
Bruce Weirdan mailto:
weirdan@gmail.com