Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109509
MIME-Version: 1.0
References: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
In-Reply-To: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
Date: Thu, 2 Apr 2020 14:27:08 +0200
Message-ID: <CAFPFaM+E+ESHNqaCR0bHVGHfx3LUsNphPPGg_xMRw-fR-9G6=A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fae23405a24deb57"
Subject: Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators
From: george.banyard@gmail.com ("G. P. B.")

--000000000000fae23405a24deb57
Content-Type: text/plain; charset="UTF-8"

On Thu, 2 Apr 2020 at 10:14, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I would like to propose making the use of arithmetic/bitwise operators on
> arrays, resources and (non-overloaded) objects a TypeError exception:
>
> https://wiki.php.net/rfc/arithmetic_operator_type_checks
>
> This is inspired by some of the recent discussions, in particular the
> operator overloading RFC (where the fact that operations on non-overloaded
> objects still succeed with just a notice was criticized) and the
> increment/decrement RFC, which handles the array case of this proposal for
> inc/dec only.
>
> I think as-is, this RFC should be completely uncontroversial. However,
> there is an open question on whether we want to make this slightly more
> strict, in order to align the semantics with the rules for weak parameter
> type checks for ints/floats.
>

On this topic maybe it would be good time to bring back again the Saner
string to number comparison RFC, at least in some form?
https://wiki.php.net/rfc/string_to_number_comparison

Or is this open question meant to replace it?

And maybe in some other form revive this RFC about allowing trailing
white-spaces in numeric string, because IMHO only accepting those
which have white-spaces in front is kinda weird.


> If we do that, then this RFC could be a stepping stone towards making
> "implicit" internal casts use the (weak) parameter type checking semantics
> more generally, which I think would be a good idea. The current explicit
> cast semantics we use everywhere are too forgiving for most circumstances
> (e.g. an array is almost always not a reasonable input where an integer is
> expected).
>
> Regards,
> Nikita
>

Other than this a solid +1 from me.

George P. Banyard

--000000000000fae23405a24deb57--