Allow null variables to be decremented

My opinion is that it'd be more consistent for -- to work like -= 1 (e.g. become -1).
It might break some code, but that code was probably incorrect.

Out of scope of the proposed RFC, but this reminds me of a similar issue:
Currently, the ++ and -- operators do nothing to arrays or objects,
not even emitting a notice or changing the value.
I see that ++ on typed properties/references can already throw a TypeError for integer overflow,
so it might make sense to also start throwing a TypeError for ++ on objects (without numeric operation handlers) and arrays.

I'd thought earlier that emitting a notice instead of throwing a TypeError for arrays/objects might negatively limit the optimizations opcache can do
because error handlers can have side effects.
But it looks like I'd just have to allow inferring that MAY_BE_OBJECT and MAY_BE_ARRAY
could have side effects for the INC/DEC opcodes in may_have_side_effects() in ext/opcache/Optimizer/dce.c.

(If your RFC ends up emitting warnings/notices, it would need to check for MAY_BE_NULL|MAY_BE_UNDEF in dce.c, I think.)

Would there be any interest in emitting a warning or deprecation warning for objects/arrays starting in php 8.0?

• Tyson

There is currently an odd inconsistency when using the decrement
operator on a null variable:

I'm not so sure...

That incrementing a null works at all is a painful part of the language
spec that I would argue needs flushing down the toilet, rather than
further reinforcing.

I recon the required precursor to doing so is erroring on undefined
variables, which I suspect accounts for about 99% of increment-on-nulls.

The majority are in favour (56%) but not the supermajority necessary -
Athough there's an argument to be made that a supermajority may exist in
a straight up or down vote rather than a 3-way
(https://wiki.php.net/rfc/engine_warnings).

So on one hand, consistency is good.

On the other hand, being consistently bad is still being bad.

--
Mark Randall
marandall@php.net

On Sat, Feb 15, 2020 at 6:44 PM Rowan Tommins rowan.collins@gmail.com
wrote:

Hi all,

There is currently an odd inconsistency when using the decrement
operator on a null variable:

$a = null; $a=$a+1; // int(1)
$a = null; $a+=1; // int(1)
$a = null; ++$a; // int(1)

$a = null; $a=$a-1; // int(-1)
$a = null; $a-=1; // int(-1)
$a = null; --$a; // null

I would like to propose changing this behaviour for PHP 8, so that --$a
would give int(-1), as I believe it is simply a long-standing bug.

This has been raised as a bug at least three times [1][2][3] but closed
as documented behaviour / too much of a BC break. It is documented in
the manual, but with no explanation of why it should work that way. [4]

I would be interested in any explanations of why it might be intended
behaviour, or ways in which people might be relying on the current
behaviour.

A proposal to change the behaviour was included in a wider RFC about
standardising increment and decrement behaviour, but it never got beyond
draft status. [5] I would prefer not to reopen that wider debate, but
focus on this single issue.

As far as I can see, the change would be to add a "case IS_NULL" branch
to decrement_function in zend_operators.c to match the one in
increment_function. [6]

I will happily write up an RFC to formalise this, but wanted to gather
people's immediate thoughts first.

Principally in favor of this change, I do think that ++ and -- should
behave consistently if nothing else. We might want to consider giving the
same treatment to false/true as well, which should be interpreted as 0/1.
That is $foo++ / $foo-- should behave the same ways as $foo+=1, $foo-=1 for
null, true, false. It seems odd to single out only "null" here.

Additionally I would suggest a notice when trying to increment arrays,
resources and objects, rather than just silently doing nothing. As long as
it's just a notice, this should have minimal BC implications.

Nikita