Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108807
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
In-Reply-To: <CADyq6sJ5ErMVg2EjUcVM17omtN+Tx_bZ69RB_4b44n-Y=oxzSw@mail.gmail.com>
Date: Mon, 2 Mar 2020 15:40:54 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <627FD99D-C38A-495F-AF7B-C1D76D4B7591@cschneid.com>
References: <3f615d82-a84b-697b-5c02-8d915270f92c@gmail.com>
 <CADyq6sJ5ErMVg2EjUcVM17omtN+Tx_bZ69RB_4b44n-Y=oxzSw@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Increment/Decrement Fixes
From: cschneid@cschneid.com (Christian Schneider)

Am 02.03.2020 um 15:00 schrieb Marco Pivetta <ocramius@gmail.com>:
> 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.
>=20
> 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:
>=20
> RFC Proposal: `$a =3D null; $a--; $a =3D=3D=3D -1`. Let's make this an =
explicit
> TypeError instead.
> RFC Proposal: `$a =3D null; --$a; $a =3D=3D=3D -1`. Let's make this an =
explicit
> TypeError instead.
>=20
> RFC Proposal: `$a =3D true; $a++; $a =3D=3D=3D 2`. Let's make this an =
explicit
> TypeError instead.
> RFC Proposal: `$a =3D true; ++$a; $a =3D=3D=3D 2`. Let's make this an =
explicit
> TypeError instead.
> RFC Proposal: `$a =3D true; $a--; $a =3D=3D=3D 0`. Let's make this an =
explicit
> TypeError instead.
> RFC Proposal: `$a =3D true; --$a; $a =3D=3D=3D 0`. Let's make this an =
explicit
> TypeError instead.
>=20
> RFC Proposal: `$a =3D false; $a++; $a =3D=3D=3D 1`. Let's make this an =
explicit
> TypeError instead.
> RFC Proposal: `$a =3D false; ++$a; $a =3D=3D=3D 1`. Let's make this an =
explicit
> TypeError instead.
> RFC Proposal: `$a =3D false; $a--; $a =3D=3D=3D -1`. Let's make this =
an explicit
> TypeError instead.
> RFC Proposal: `$a =3D false; --$a; $a =3D=3D=3D -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
>=20
> 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.=20

- Chris