On Fri, 5 May 2023 at 15:49, Derick Rethans <der...@php.net> wrote: > 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. >
Yes, this is what I mean by "compatible with int". > | 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. > This is not how file/stream resources work. The resource number is not correlated to the file descriptor. The only cases where this is the case are the predefined streams STDIN, STDOUT, and STDERR. This is part of the reason for needing a new function like the file_descriptor() function I'm proposing. [1] > | Throw a ValueError when passing a negative $step for increasing > | ranges. > > I think that's a BC break that is not worthy of making. > There is no impact shown, and it doesn't make sense to pass a negative $step. This can be changed to a deprecation but considering there is no impact I don't see why we should wait. | 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? > Yes, this was implied. As we are only concerned about the "pure string" case here. But I have clarified this. | 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 deprecation is just a consequence of finally using ZPP, thus invoking the previously accepted RFC. > > 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. Disagree, the implementation is already complicated, and trying to support the current absurd behaviour is impractical, especially as no impact has been found. Best regards, George P. Banyard [1] https://wiki.php.net/rfc/file-descriptor-function
