• Date: 2020-04-02
• Author: Nikita Popov [email protected]
• Status: Implemented
• Target Version: PHP 8.0
• Implementation: https://github.com/php/php-src/pull/5331

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 +, -, *, /, **:

• Throw Error exception on array operand. (Excluding + if both operands are array.)
• Silently convert a resource operand to the resource ID as an integer.
• Convert an object operand to integer one, while throwing a notice.

Operators %, <<, >>, &, |, ^:

• Silently convert an array operand to integer zero if empty or integer one if non-empty.
• Silently convert a resource operand to the resource ID as an integer.
• Convert an object operand to integer one, while throwing a notice.

Operator ~:

• Throw an Error exception for array, resource and object operands.

Operators ++ and --:

• Silently do nothing if the operand is an array, resource or object.

The proposed behavior is the same for all the arithmetic/bitwise operators +, -, *, /, **, %, <<, >>, &, |, ^, ~, ++, --:

• Throw a 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:

• Make non-numeric string operands throwing. Non-numeric here means not starting with a digit (optionally preceded by whitespace). This would not apply to operators that have special behavior for strings (string increment and bitwise and/or/xor).
• Make overflowing float values throwing for operators that expect an integer (%, <<, >>, &, |, ^).

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.

Add stricter type checks for arithmetic/bitwise operators?
Real name	yes	no
ajf (ajf)
alcaeus (alcaeus)
asgrim (asgrim)
ashnazg (ashnazg)
brzuchal (brzuchal)
bwoebi (bwoebi)
carusogabriel (carusogabriel)
cmb (cmb)
colinodell (colinodell)
daverandom (daverandom)
derick (derick)
dmitry (dmitry)
duncan3dc (duncan3dc)
duodraco (duodraco)
ekin (ekin)
galvao (galvao)
gasolwu (gasolwu)
girgias (girgias)
jasny (jasny)
jbnahan (jbnahan)
jhdxr (jhdxr)
jmcastagnetto (jmcastagnetto)
kelunik (kelunik)
kguest (kguest)
klaussilveira (klaussilveira)
kocsismate (kocsismate)
lcobucci (lcobucci)
malukenho (malukenho)
marandall (marandall)
marcio (marcio)
mariano (mariano)
mbeccati (mbeccati)
mcmic (mcmic)
mike (mike)
narf (narf)
nicolasgrekas (nicolasgrekas)
nikic (nikic)
ocramius (ocramius)
petk (petk)
pmmaga (pmmaga)
pollita (pollita)
rasmus (rasmus)
reywob (reywob)
royopa (royopa)
ruudboon (ruudboon)
salathe (salathe)
sammyk (sammyk)
sebastian (sebastian)
sergey (sergey)
sirsnyder (sirsnyder)
stas (stas)
svpernova09 (svpernova09)
tandre (tandre)
trowski (trowski)
wyrihaximus (wyrihaximus)
yunosh (yunosh)
zimt (zimt)
Final result:	57	0
This poll has been closed.