Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119299
Message-ID: <4a676ff4-bbd6-31b1-7055-8cd7f6894a54@gmail.com>
Date: Tue, 17 Jan 2023 19:46:20 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
To: internals@lists.php.net
References: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: rowan.collins@gmail.com (Rowan Tommins)

On 17/01/2023 14:28, 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;


Hi George,

Thanks for tackling this. I heartily agree with the aims of this RFC; 
the current situation is a weird mess of special cases, most of which 
are justified only by "it's always been that way".


> I am expecting the contentious part of the proposal to be the deprecation
> of the PERL string increment feature to achieve the aforementioned goal.


As Craig and Mark point out, this functionality does have legitimate 
uses, and I am generally of the opinion that deprecations should either 
be of broken functionality (as is often the case when upgrading Warnings 
to Errors) or come with specific instructions for a replacement.

Perhaps therefore we should introduce a new function, string_inc, as the 
official migration path for deliberate use of this feature. This could 
give the same result as the current increment operator for supported 
cases, but throw an Error for cases that would currently be left 
unchanged. A polyfill using the existing operator on old versions would 
look something like this:

function string_inc(string $input): string {
     $output = $input;
     @ ++$output;
     if ( $input === $output ) {
         throw new Error("Unsupported input to string_inc: '$input'");
     }
     return $output;
}

Without the need to interact with other types or existing behaviour, I 
think an accompanying string_dec would also be less controversial than 
previous RFCs. Ambiguous cases like string_dec("a"), string_dec(""), and 
string_dec("0") could simply throw an Error.


Regards,

-- 
Rowan Tommins
[IMSoP]