On Fri, 20 Jan 2023 at 18:28, Mark Baker <m...@demon-angel.eu> wrote:
> The documentation page consistently uses the word Increment and > Decrement, not Add 1 and Subtract 1. > > Developers who read the documentation should be aware of the Perl > convention when dealing with alphabetic strings, and should expect that > behaviour. Alphanumeric strings are certainly more problematic, less > well documented, and less well understood, and I'll agree that they're > inconsistent in their behaviour. > The PHP documentation has never been the source of truth about the PHP implementation, if it was dynamics properties should have been removed without any notice as until them being deprecated there was no documentation. So arguing *something* should behave a certain way because the docs are written in a certain way holds no value to me. The state of the PHP docs could certainly be improved, as it is blatantly lying at various core sections. However, the whole point of this RFC is to *remove* cognitive burden for developers, so they don't even need to be aware of this "feature" and not get surprised when it kicks in. Moreover, by your logic, you wouldn't care if we removed support for alphanumeric strings and only let the PERL increment kick in for purely alphabetical. While convenient for you, someone might actually use this feature on alphanumeric strings, and we're back to "why is my use case being removed while that other just as weird one remains". I even went initially for such a proposal (see previous revision [1]), however, I realized this provides minimal benefit as it doesn't reduce at all the cognitive burden or the overall design specification of the language. > Deprecating the Increment operator for strings will create extra work > for me, will affect many of the users of my library, and I'm certain it > will also have a performance impact on the library (replacing that > operation with a more expensive function call for alpha increments, but > still having the operation for numeric increments). So yes, I am willing > to die on this hill because that deprecation will have a very direct and > adverse affect on my work. > If the issue is about performance, it is possible to enhance the optimizer to inline those two functions (something the optimizer already attempts to do for userland functions [2]). The other aspect goes back to the typical conundrum: Do we think PHP is in decline? - If yes, then not doing breaking changes and catering to legacy projects is definitely the course of action to take. - If no, improving PHP for the next generation of developers and software, so that it is easier to learn and reason about, should be the course of action to take. As I personally think we are in the second situation, that's why I'm tackling this subject in this manner. It's the same belief that made us deprecate dynamic properties, convert warnings to Errors, etc. Now, if we are in the former case, then you are totally justified, and I probably should find another job as I see no point in not improving the overall language semantics. George P. Banyard [1] https://wiki.php.net/rfc/saner-inc-dec-operators?rev=1669977388 [2] See zend_try_inline_call() function
