Re: [RFC] Path to Saner Increment/Decrement operators

On 23/01/2023 14:06, G. P. B. wrote:

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 make no judgement on alphanumeric strings, other than I can't see any use case for it myself, so I won't allow my objection be considered hypocritical; and your definition of my use case as "weird" is highly judgemental. Bijective numeration using the letters of the alphabet has a long and ancient tradition, pre-dating our modern numeric Hindu-Arabic system using base 10 for place/value notation by many centuries. The Abjadi system used the 28 letters of the Arabic alphabet; similarly the ancient Greeks and Hebrews, the Armenians; by Russia until the early 18th Century (each culture using their own alphabet). It's ironic that the Romans used a very different system, even though our modern western alphabet is based on the Roman alphabet. These civilisations didn't consider their alphabetic numeral system "weird". How many of the irregularities and idiosyncracies of alphanumeric strings could be resolved by not trying to cast them as a numeric value before increment/decrement; but by treating them consistently as strings? It would resolve the discrepancy with "5d9"; although not with "0xf9". -- Mark Baker