Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119380
MIME-Version: 1.0
References: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
 <5FC8DBAF-8D78-4E94-A3B0-3BDED3A3E53C@craigfrancis.co.uk> <789af205-4582-66a9-694a-10e18b8b9f56@demon-angel.eu>
 <CAFPFaMLAnCqhPFZHQXnABbw=aXXj53DwtaDOf=+zQ4jN1Z+OmA@mail.gmail.com>
 <9d225219-4e31-b362-52a9-9a298a0a55ef@telia.com> <CAFPFaM+X=H_qsVC2Nr-Qte52D0BQYxoJTxHCeh0qZNaH-ofoZg@mail.gmail.com>
 <768de46c-9ff2-eee2-24ab-e78e27ad167c@demon-angel.eu>
In-Reply-To: <768de46c-9ff2-eee2-24ab-e78e27ad167c@demon-angel.eu>
Date: Fri, 20 Jan 2023 17:43:24 +0000
Message-ID: <CAFPFaMJ362LKMcGK1=zkiUeA7pdsY=XYgtg49EfuQ32yP9LVUQ@mail.gmail.com>
To: Mark Baker <mark@demon-angel.eu>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c41d6005f2b596fa"
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: george.banyard@gmail.com ("G. P. B.")

--000000000000c41d6005f2b596fa
Content-Type: text/plain; charset="UTF-8"

On Thu, 19 Jan 2023 at 00:23, Mark Baker <mark@demon-angel.eu> wrote:

>
> On 18/01/2023 21:25, 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.
>
> However, the ++ and -- are the "Increment" and "Decrement" operators,
> not the Add1 and Subtract1 operators; while they behave in that way when
> used with variables containing numeric values, they are special
> operators and not simply a syntactic sugar for +=1 and -=1. As long as
> their behaviour is consistent, and definition of what "Increment" and
> "Decrement" mean is clearly defined for different datatypes, then I feel
> that the PERL-style alpha string increment has enough valid use cases to
> justify itself.
>

That's a strange hill to die on, most people would expect that those
operators do indeed behave like Add1 and Sub1, and clearly you are not
having any issue with making -- act like Sub1.
There is even a user note on the manual page from 21y ago where someone was
expecting booleans to be incremented. [1]
Moreover, the alphanumeric string increment feature is fundamentally broken
and unsound due to the simple fact that PHP supports converting numeric
strings written in scientific notation to float.
And this behaviour of casting a numeric string in scientific notation
*always* takes precedent over the alphanumeric increment.
The following code samples show this perfectly:
$s = "5d9";
var_dump(++$s); // string(3) "5e0"
var_dump(++$s); // float(6)
$s = "5e9";
var_dump(++$s); // float(5000000001)
var_dump(++$s); // float(5000000002)

Behaviour that *also* has a user note on the manual page. [2]

It is possible to have a sound implementation of it in userland, via the
following function:
function polyfill(string $s): string {
    if (is_numeric($s)) {
        $offset = stripos($s, 'e');
        if ($offset !== false) {
            /* Using increment operator would cast the string to float
             * Therefore we manually increment it to convert it to an
"f"/"F" that doesn't get affected */
            $c = $s[$offset];
            $c++;
            $s[$offset] = $c;
            $s++;
            $s[$offset] = match ($s[$offset]) {
                'f' => 'e',
                'F' => 'E',
                'g' => 'f',
                'G' => 'F',
            };
            return $s;
        }
    }
    return ++$s;
}


> We might also discuss consistency of datatype changes when these
> operators are used.
>
> $a = PHP_INT_MAX;
>
> ++$a;
>
> or
>
> $a = '10';
>
> ++$a;
>
> both change the datatype of $a; which isn't documented behaviour either.
>

Those are just "regular" well documented type coercions due to addition and
int to float promotions.
And yes, the PHP documentation could be better, but no one is paid to work
on it.
However, it turns out that I only work part-time for The PHP Foundation,
and therefore I am available to be hired to do some technical writing for
the PHP Documentation.
(If anyone does want to take me up on this offer, do feel free to email me).

In any case, I've updated the RFC to version 0.3, [3] with a whole section
about the current behaviour of the PERL increment implementation in PHP, a
native implementation of str_increment() and str_decrement() that handles
strings that can be interpreted as numbers written in scientific notation.
It also changes the timeline slightly, as this seems the preferred course
of action.

Best regards,

George P. Banyard

[1] https://www.php.net/manual/en/language.operators.increment.php#16149
[2] https://www.php.net/manual/en/language.operators.increment.php#109621
[3] https://wiki.php.net/rfc/saner-inc-dec-operators

--000000000000c41d6005f2b596fa--