On Thu, 19 Jan 2023 at 00:23, Mark Baker <m...@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
