Am 28.03.2023 um 14:42 schrieb G. P. B. <george.bany...@gmail.com>:
> On Tue, 28 Mar 2023 at 08:19, Christian Schneider <cschn...@cschneid.com>
> wrote:
>> There are two cases I would handle differently:
>> - I'm not sure why a negative step for $start > $end is considered wrong, I
>> consider range(10, 0, -2) at least as logical/readable as using a positive
>> decrement of 2. Not requiring a sign for steps seems weirder to me but
>> that's something we cannot change. *BUT* if it is the result of a
>> calculation it seems wrong to require an abs() around it. I do see the
>> reason for a warning/error when $start < $end and $step < 0.
>>
> Considering the only other programming language that I know of that has a
> range() function that accepts a step argument is Python, and its behaviour is
> IMHO worse.
> For increasing ranges it requires a positive step, and if not just generates
> an empty range. For decreasing ranges it requires a negative step, and if not
> just generates an empty range (this applies even if using the default step
> value of 1 which is bonkers).
>
> Making it a requirement to pass a negative step is definitely out of the
> question.
> Making it okay to use negative steps *only* for decreasing ranges could be
> sensible, but we check for the step parameter way before we look into the
> boundary values because those are different for int, float and string
> boundaries.
> Moreover, I personally find it weirder to require a sign for negative steps
> as for me a step is something that *must* be positive
I quickly checked our own codebase and there is indeed one instance of
range($last, 0, -1)
which was not written by me so there is at least one more person who found this
logical ;-)
>> - Values of '' or null in integer context (e.g. range(null, 10, 2)) should
>> IMHO emit a warning first, not directly be changed to a TypeError. The usual
>> BC / migration concern :-)
>
> Trying to figure out if an empty string was used with another string boundary
> is tedious, as this information needs to somehow get carried around.
> A previous iteration of the PR used to convert empty strings to 0 with a
> warning, but considering the analysis I decide to just make this a ValueError
> as it doesn't seem that empty strings are actually used in practice.
> But this is an easy revert, and I'm not really bound to this decision.
Even though this might be a bit cumbersome at the moment I think this would be
an important transition step as currently
range('', 10, 2);
returns the (somewhat) expected result of 0, 2, 4, 6, 8, 10 so I'd be in favor
of first giving a warning and then changing it to a ValueError.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
