Re: [RFC] Define proper semantics for range() function

On 28/03/2023 00:36, G. P. B. wrote:

Hello internals, While working on analysing the impact of the changes proposed by amending the behaviour of the increment and decrement operators ( https://wiki.php.net/rfc/saner-inc-dec-operators) I discovered that the range() function has some rather lax behaviour that is very unintuitive. I therefore propose the "Define proper semantics for range() function" RFC to address the unintuitive behaviour that sees no usage and/or hide bugs: https://wiki.php.net/rfc/proper-range-semantics The change propose to throw TypeErrors and ValueErrors for case where I couldn't find occurrences in the wild and hide bugs, and emit some E_WARNINGs for cases that are hard to detect via static analysis.

Unlike your changes to the increment operator, I'd love to see this rationalisation put in place, though like many here I don't see problems with using a negative step with decreasing ranges, but would consider it strange for increasing ranges. And I do want to see some case-consistency when working with string ranges. I'd love to see it taken a stage (or two) further; returning an iterable rather than an array (although that would be a bc break); and working with strings (ASCII only) in the same way that the increment operator does, so that range('A', 'IV') would be valid, and return Z then AA, AZ then BA, etc. I am slightly surprised that you make no mention of the odd behaviour of mixed alphameric strings, e.g. var_dump(range('A1', 'C5')) which returns a purely alpha array 'A' to 'C'; or var_dump(range('3c', '5e')) which returns numeric (3, 4, 5); or var_dump(range('1', '1e2')) which treates 1e2 as scientific and returns 1..100. -- Mark Baker