On Mon, 27 Mar 2023, G. P. B. wrote: > 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
| If $step is a float but is compatible with int interpret it as an | integer. I guess you mean with that "the fraction is '.0'" and "-2^52 < number < 2^52" ? What is also going to be playing up is the range of $start and $end itself. | Introduce and use a proper ZPP check for int|float|string $start and | $end parameters, this will cause TypeErrors to be thrown when passing | objects, resources, and arrays to range(). I am not sure whether it wise to disallow resources. These are often file descriptors and having a range on those *could* make sense? Not fussed much either way though. | Throw a ValueError when passing a negative $step for increasing | ranges. I think that's a BC break that is not worthy of making. | Emit an E_WARNING when $start or $end has more than one byte. Surely only if the string doesn't represent an int or float? | var_dump(range(null, 2)); I think that safely can be interpreted as range(0, 2) — I wouldn't throw a deprecation warning for that... but then of course, we do already have a similar (deprecation) warning for arguments. > > 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. | Target Version: PHP 8.3 In my opinion that's not a good thing. There are a fair amount of BC breaks (beyond the one that I oppose to with nagative steps throwing an ValyeError), without first having deprecations. IMO, the actual BC breaks here should become deprecations in 8.X and BC can only be really broken in 9.0. cheers, Derick
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
