PHP: rfc:arithmetic_operator_type_checks

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== PHP RFC: Stricter type checks for arithmetic/bitwise operators ======
  * Date: 2020-04-02
  * Author: Nikita Popov <nikic@php.net>
  * Status: Implemented
  * Target Version: PHP 8.0
  * Implementation: https://github.com/php/php-src/pull/5331

===== Introduction =====

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:

<PHP>
var_dump([] % [42]);
// int(0)
// WTF?
</PHP>

Let's fix it.

===== Proposal =====

==== Current Behavior ====

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.

==== Proposed Behavior ====

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.

==== Unchanged Behavior ====

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 [[rfc:strict_operators|strict operators directive]].

The changes proposed here are intended to be entirely uncontroversial.

===== Backward Incompatible Changes =====

Using an array, resource or object in an arithmetic/bitwise operation will now consistently throw, while it previously produced a non-sensical value.

===== Future Scope =====

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.

===== Vote =====

Voting started 2020-04-16 and ends 2020-04-30.

<doodle title="Add stricter type checks for arithmetic/bitwise operators?" auth="nikic" voteType="single" closed="true">
   * yes
   * no
</doodle>
Page Tools
