Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108802
MIME-Version: 1.0
References: <3f615d82-a84b-697b-5c02-8d915270f92c@gmail.com>
In-Reply-To: <3f615d82-a84b-697b-5c02-8d915270f92c@gmail.com>
Date: Mon, 2 Mar 2020 15:00:21 +0100
Message-ID: <CADyq6sJ5ErMVg2EjUcVM17omtN+Tx_bZ69RB_4b44n-Y=oxzSw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000631fbe059fdf9cde"
Subject: Re: [PHP-DEV] [RFC] Increment/Decrement Fixes
From: ocramius@gmail.com (Marco Pivetta)

--000000000000631fbe059fdf9cde
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Rowan,

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.

Changing the current behavior, regardless in which way, is a BC break:
might as well make the BC break useful:

RFC Proposal: `$a =3D null; $a--; $a =3D=3D=3D -1`. Let's make this an expl=
icit
TypeError instead.
RFC Proposal: `$a =3D null; --$a; $a =3D=3D=3D -1`. Let's make this an expl=
icit
TypeError instead.

RFC Proposal: `$a =3D true; $a++; $a =3D=3D=3D 2`. Let's make this an expli=
cit
TypeError instead.
RFC Proposal: `$a =3D true; ++$a; $a =3D=3D=3D 2`. Let's make this an expli=
cit
TypeError instead.
RFC Proposal: `$a =3D true; $a--; $a =3D=3D=3D 0`. Let's make this an expli=
cit
TypeError instead.
RFC Proposal: `$a =3D true; --$a; $a =3D=3D=3D 0`. Let's make this an expli=
cit
TypeError instead.

RFC Proposal: `$a =3D false; $a++; $a =3D=3D=3D 1`. Let's make this an expl=
icit
TypeError instead.
RFC Proposal: `$a =3D false; ++$a; $a =3D=3D=3D 1`. Let's make this an expl=
icit
TypeError instead.
RFC Proposal: `$a =3D false; $a--; $a =3D=3D=3D -1`. Let's make this an exp=
licit
TypeError instead.
RFC Proposal: `$a =3D false; --$a; $a =3D=3D=3D -1`. Let's make this an exp=
licit
TypeError instead.

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).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Sun, Mar 1, 2020 at 10:23 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> Hi all,
>
> Following my thread a couple of weeks ago, I would like to put forward
> an RFC to fix some inconsistencies with the behaviour of the ++ and --
> operators:
>
> https://wiki.php.net/rfc/increment_decrement_fixes
>
> Note that this RFC focusses on three specific cases which I think could
> be considered bugs, but require breaking compatibility:
>
> 1) Bring the behaviour of decrementing null in line with subtracting 1
> (and with the equivalent increment operator)
> 2) Bring the behaviour of incrementing or decrementing true and false in
> line with adding or subtracting 1
> 3) Throw the same error when incrementing or decrementing an array as
> when adding or subtracting 1
>
> I believe the behaviour of strings, objects, and resources, each raise
> sufficient extra questions that they should be left to future RFCs where
> we can focus on each in more detail.
>
> Please read the RFC for more detail on what is and isn't proposed.
>
> Regards,
>
> --
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000631fbe059fdf9cde--