[RFC] Increment/Decrement Fixes

Hi Alexandru,

On 2 March 2020 09:22:57 GMT+00:00, "Alexandru Pătrănescu"
[email protected] wrote:

For point 1 and 2, both the old and new behavior is silent. Can we
think of
a safer way to migrate?

That's a very good question, and one I don't have a particularly good answer to.

The problem with this kind of behaviour change is that there's no way
for PHP to know whether a particular piece of code has been changed to
expect the new behaviour or not, and therefore whether to raise a
deprecation notice. An opt-in notice on all usages could allow the
user to build up a list of places in their code to check, but they'd
still need to manually track which they'd already looked at, so I'm
not sure how useful it would be.

What I will look into is how well static analysis tools such as
PHPStan and Psalm could build a similar list, as I think that's
generally a more useful approach.

Regards,

Rowan Tommins
[IMSoP]

Hi Marco,

Overall against the RFC: ++ and -- (prefix and suffix) are supposed to
be used with numeric values, not with other types, as that makes everything
only more confusing.

While I'm generally sympathetic to that principle, it could also be said of
the + and - operators, which currently silently handle both nulls and
booleans. I would be open to changing all arithmetic behaviour,
particularly on booleans, but don't think a vague ambition for that
justifies inconsistent behaviour between different arithmetic operators.

Code written (intentionally) to use ++ and -- against non-numeric
values should NOT pass a code review, and I am sorry for those that
have to maintain it if that happens.

I think you're taking simplified examples too literally here, and assuming
that all affected code would be obvious at a glance.

Take for instance this innocent-looking patch:

function foo($bar) {

• $bar -= 1;
  

• $bar--;
  // more code here
  }

With the current behaviour, any inadvertent calls to the function passing
null, true, false, or an array will change behaviour when this patch is
merged. In particular, the variable $bar would previously have been
guaranteed to be an integer, and will now retain the original type passed
in.

I completely agree that such code has a bug, but the difference in
behaviour is still a massive WTF.

The asymmetry of ++ and -- is even more confusing. Consider this patch:

function repeatThing($extraTimes) {

•  for ( $i = 0; $i <= $extraTimes ; $i ++ ) {
  

• for ( $i =  $extraTimes ; $i >= 0; $i -- ) {
       doThing();
   }
  

  }

Again, this looks like a safe change - but if passed a value of NULL, the
old code will call doThing() once, and the new code will enter an infinite
loop.

This asymmetry is the primary problem I want to address with this RFC.

Changing the current behavior, regardless in which way, is a BC break:
might as well make the BC break useful:

RFC Proposal: $a = null; $a--; $a === -1. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = null; --$a; $a === -1. Let's make this an explicit
TypeError instead.

And what about $a = null; $a++; / $a = null; ++$a;, which currently
has behaviour consistent with other arithmetic operations (in particular,
is identical to $a+=1) and this RFC does not propose to change?

If we change the ++ case to throw a TypeError, would we also change null+1
to throw one? And would we then also examine all the other operators and
utility functions which silently coerce null to zero or an empty string?

I'd rather not go down that rabbit hole to fix something which is seemingly
just a bug in the implementation. If an RFC passes that makes all
arithmetic on NULL an error in PHP 8.0 (i.e. with no deprecation period),
my RFC will be redundant; but that seems unlikely.

I am less precious about the changes to boolean, which is why I propose
three separate votes. I would be open to an alternative RFC removing all
implicit casts on boolean, object, and resource; but unless and until
undefined variable behaviour changes, null is necessarily a special case.

Regards,

Rowan Tommins
[IMSoP]

Am 02.03.2020 um 15:00 schrieb Marco Pivetta [email protected]:

Overall against the RFC: ++ and -- (prefix and suffix) are supposed to
be used with numeric values, not with other types, as that makes everything
only more confusing.

Code written (intentionally) to use ++ and -- against non-numeric
values should NOT pass a code review, and I am sorry for those that
have to maintain it if that happens.

There are still those who find
$wordcount[$word]++;
useful enough to support both ++ on null as well as usage of uninitialised array indices.

Please respect this kind of code, it is out there and fully functional.

Changing the current behavior, regardless in which way, is a BC break:
might as well make the BC break useful:

RFC Proposal: $a = null; $a--; $a === -1. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = null; --$a; $a === -1. Let's make this an explicit
TypeError instead.

RFC Proposal: $a = true; $a++; $a === 2. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = true; ++$a; $a === 2. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = true; $a--; $a === 0. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = true; --$a; $a === 0. Let's make this an explicit
TypeError instead.

RFC Proposal: $a = false; $a++; $a === 1. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = false; ++$a; $a === 1. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = false; $a--; $a === -1. Let's make this an explicit
TypeError instead.
RFC Proposal: $a = false; --$a; $a === -1. Let's make this an explicit
TypeError instead.

I don't care too much about -- but if you want to discourage ++ on those types then make it E_STRICT, E_NOTICE or even E_WARNING.
Similar for non-numeric increments.

In addition to that, we may propose removal of ++, -- and similar
from non-numeric types (will lead to TypeError) like Andrea started in
https://wiki.php.net/rfc/invalid_strings_in_arithmetic

It makes no sense to keep a landmine there: let's get rid of it, instead of
empowering it further (and breaking BC too, while doing so).

I see your point and I can live with E_* but breaking well-defined and functioning code because you don't like $null++ is wrong.

• Chris

https://wiki.php.net/rfc/increment_decrement_fixes

It reads better than before.

IMO option c) is definitely the absolutely superior option for the
long-term health of the ecosystem, of that I have absolutely no doubt at
all.

Simply, if it's arithmatic on something that's not a number, and isn't
an overloaded object, it should throw.

But that seems like it's too far away... so I could maybe get behind
subtracting from null becoming -1, but I really don't like it.

It just feels so wrong, but the only thing that feels worse is that we
probably couldn't pass removing null++, at least in the base version,
and that may set up null-- as the least-worst option.

--
Mark Randall