Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119314
Date: Wed, 18 Jan 2023 15:32:28 +0000 (GMT)
To: "G. P. B." <george.banyard@gmail.com>
cc: PHP internals <internals@lists.php.net>
In-Reply-To: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
Message-ID: <alpine.DEB.2.23.453.2301181523100.23089@singlemalt.home.derickrethans.nl>
References: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
User-Agent: Alpine 2.23 (DEB 453 2020-06-18)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: derick@php.net (Derick Rethans)

On Tue, 17 Jan 2023, G. P. B. wrote:

> 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;

If that is the goal, then I would agree with this RFC.

However, changing the PERL string increment feature does not IMO fit 
into that goal, and it also a useful *feature*. On that base I would 
vote against this. And I suspect many others would as well.

Is there a way to avoid this single useful feature from being 
deprecated, while to good parts of this RFC stay?

I am also unsure as how much actual breakage this would cause, and 
before this gets up to a vote, I would like to see how bad (or not) this 
would affect already existing code bases.

cheers,
Derick