On Tue, 17 Jan 2023 at 18:28, Mark Baker <m...@demon-angel.eu> wrote:
> On 17/01/2023 17:28, Craig Francis wrote: > > I've seen this used a few times, e.g. starting with a numerical value > (Passport number, NHS number, Social Security Number, Date of Birth > 20230117), and the developer simply appends an incrementing letter on the > end to get a unique reference; e.g. a person having multiple assessments... > especially if it's more than 26 (A-Z), and you need to move to multiple > letters, which `chr(90 + 1)` cannot help you with. > > Being able to increment alpha strings is incredibly useful when working > with Excel spreadsheets (as I do on a daily basis), because the column > Ids match this pattern; and I would hate to see this deprecated. Having > to replicate that logic for traversing column Ids in userland code would > be inconvenient (to say the least), would affect many of the users of my > libraries, and would have a performance impact on my libraries. If > anything, I'd rather like to see the decrement operator work with alpha > strings as well for more consistency. > > I don't have the karma for a vote; but if I did then it would be a "No" > for this alone, because I can see the problems that it will cause me and > the users of my libraries. > > > > That said, I appreciate that incrementing some strings can be a bit > unusual (e.g. "A9" to "B0", vs "A 9" to "A 0"). > > Agreed. While incrementing works in a very logical manner with mixed > alphanumeric strings, it's not well documented behaviour, and most > developers take a long time before they understand what it's actually > doing. While there might be use cases for incrementing alphanumerics, I > suspect that it would be better implemented in the business logic of an > application, because the component parts of that string are likely to > have business meaning; and also to provide better code readability. > I appreciate being shown concrete cases about the useful ness of this operation. The reason I didn't go with adding support for decrementing alphanumeric strings is that it was unanimously rejected. However, if Rowan's suggestion of adding string_increment()/string_decrement() with more rigorous behaviour (that we can flesh out together) would be part of this proposal, would you be more inclined to accept deprecating ++ from performing this feature? I truly believe having $v++ behave like $v += 1 and $v-- behave like $v -= 1; is something to strive for *because* it allows us to remove one dedicated type juggling context people need to be aware of and simplifies the overall semantics of the language. Keeping support for string increments means that one cannot interchange $v++ and $v += 1 and that one needs to be aware about using it when a value might hold a string. As such, if it needs to remain its own type juggling context, the question is why not make it stricter by having it warn and then throw a TypeError on bool, reopening the can of worms that is the null handling between both operators and what to do with the empty string case. These questions are already answered by making those operators behave just like addition/subtraction. My order of preference for the semantics are as follows: 1. The behaviour described in the RFC (with or without function for string in/decrement) 2. (with a massive gap, but I could live with it) adding support for string decrements and tiding up the behaviour of the alphanumeric string to make it stricter and less error-prone. 3. The current asymmetry (again with a massive gap between this and option 2) But because option 2 seems out of the question due to the unanimous rejection of https://wiki.php.net/rfc/alpanumeric_decrement, the only viable options to me seem like 1 and 3. As I hate option 3 I am pushing for option 1 as I think it has various benefits. Moreover, I do not want to split this into its own proposal (deprecating string increments/figuring out what to do with them) as I feel it will make any attempt to improve the situation harder. Best regards, George P. Banyard
