Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119386
MIME-Version: 1.0
References: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
In-Reply-To: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
Date: Fri, 20 Jan 2023 11:44:28 -0800
Message-ID: <CAMrTa2FKRrv8=Cr5tgs3_QSwo329Ta_k74sVW2smJXL6vNO-jQ@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000091550905f2b7451b"
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000091550905f2b7451b
Content-Type: text/plain; charset="UTF-8"

On Tue, Jan 17, 2023 at 6:28 AM G. P. B. <george.banyard@gmail.com> wrote:

> Hello Internals,
>
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> The goal of this RFC is to reduce language complexity by making $v++ behave
> like $v += 1 and $v-- behave like $v -= 1;
>
> I am expecting the contentious part of the proposal to be the deprecation
> of the PERL string increment feature to achieve the aforementioned goal.
> However, I believe the benefits of aligning the behaviour of the
> increment/decrement operators with addition/subtraction are larger than
> keeping support for the PERL increment, which in its current state has
> various shortcomings.
>
> Best regards,
>
> George P. Banyard
>

I don't see a section in the RFC about JIT or anything related to OpCache,
but I know from experience with the Operator Overloads RFC that there are
several architecture specific assembly optimizations for ++ and --. Have
these been considered, and how will they be impacted?

Jordan

--00000000000091550905f2b7451b--