Re: [RFC] Define proper semantics for range() function
| From: | Christian Schneider | Date: | Tue, 28 Mar 2023 07:19:19 +0000 |
| Subject: | Re: [RFC] Define proper semantics for range() function | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119750@lists.php.net to get a copy of this message | ||
Am 28.03.2023 um 00:36 schrieb G. P. B. <george.banyard@gmail.com>:
> 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.
I think it makes sense to clean up the range() function, thanks!
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.
- 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 :-)
Regards,
- Chris