On Thu, 16 Jul 2020 at 15:39, Marco Pivetta <ocram...@gmail.com> wrote:
> 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
