This RFC proposes to throw a TypeError
when an arithmetic or bitwise operator is applied to an array, resource or (non-overloaded) object. The behavior of scalar operands (like null) remains unchanged
I think we can all agree that this is not reasonable behavior:
var_dump([] % [42]); // int(0) // WTF?
Let's fix it.
This section describes the current behavior, limited only to the cases where one operand is an array, resource or object. The object cases always assume that no operator or cast overloading is involved. If operator/cast overloading is used, then those overloads apply.
Operators +
, -
, *
, /
, **
:
Error
exception on array operand. (Excluding +
if both operands are array.)
Operators %
, <<
, >>
, &
, |
, ^
:
Operator ~
:
Error
exception for array, resource and object operands.
Operators ++
and --
:
The proposed behavior is the same for all the arithmetic/bitwise operators +
, -
, *
, /
, **
, %
, <<
, >>
, &
, |
, ^
, ~
, ++
, --
:
TypeError
exception for array, resource and object operands.Of course, the case of addition with two array operands remains legal.
The behavior of operands of type null
, bool
, int
, float
and string
remains the same.
While it is questionable whether true / 17
really is a sensible operation, the handling of scalar values in general can likely not be changed unconditionally, and as such is left to a proposal like the strict operators directive.
The changes proposed here are intended to be entirely uncontroversial.
Using an array, resource or object in an arithmetic/bitwise operation will now consistently throw, while it previously produced a non-sensical value.
In the future, we may wish to go one step further:
%
, <<
, >>
, &
, |
, ^
).
This would have the advantage of aligning the semantics with parameter type checks in coercive mode, for the types int
and int|float
depending on operator. The only discrepancy would be in the handling of null
, which is already not as strictly enforced.
I'm leaving this potential improvement out of this RFC, because it requires more consideration regarding backwards compatibility and overall language integration.
Voting started 2020-04-16 and ends 2020-04-30.