I like this proposal and I support making the language consistent. I wasn't aware there were so many inconsistencies with increment/decrement operators.
When I read the RFC I was a little sceptical about the deprecation of string increment functionality. It's something I used in the past and I see no easy upgrade path. However, after reading this thread and thinking it over, I realize that deprecation is the right way to go. Someone said that it's useful when working with Excel. Excel uses bijective base-26 system. PHP does not. I cannot even explain what logic governs PHP string increment functionality. ``` $s = "az"; var_dump(++$s); // string(2) "ba" $s = "a9"; var_dump(++$s); // string(2) "b0" $s = "99"; var_dump(++$s); // int(100) $s = "zZ"; var_dump(++$s); // string(3) "aaA" $s = "9D9"; var_dump(++$s); // string(3) "9E0" $s = "9E0"; var_dump(++$s); // float(10) $s = "CHEAP BED"; var_dump(++$s); // string(9) "CHEAP BEE" ``` Strings should not be incrementable unless they are numeric strings. The current "feature" is more like a bug from xkcd comic. https://xkcd.com/1172/ But as there is a real need for a similar functionality, for example when working with Excel, I would propose to add a class into the language that is able to calculate and iterate any bijective base system. It needs to have a clear functional spec and should support both increment/decrement operators as well as iterators. I see this as the only way out of this mess. This RFC needs to pass, but it cannot pass without an alternative for people who actually use this "feature". The PHP manual says: "The increment/decrement operators only affect numbers and strings. Arrays, objects, booleans and resources are not affected. Decrementing null values has no effect too, but incrementing them results in 1." But that's not true. You cannot increment an array or resource as it would trigger an error. But incrementing false/true doesn't generate any errors. It's very inconsistent and misleading.
