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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
