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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
