Re: [RFC] Stricter type-checks for arithmetic/bitwise operators
| From: | G. P. B. | Date: | Thu, 02 Apr 2020 12:27:08 +0000 |
| Subject: | Re: [RFC] Stricter type-checks for arithmetic/bitwise operators | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109509@lists.php.net to get a copy of this message | ||
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