Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119783
Message-ID: <d445b78a-1df3-0b16-1e43-f7d92dd9103a@demon-angel.eu>
Date: Thu, 30 Mar 2023 04:50:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Content-Language: nl
To: internals@lists.php.net
References: <CAFPFaMJ1opg7=SZ2ovFiAqjO_z1avpcNPFWTOoOqjhptoxSvcg@mail.gmail.com>
In-Reply-To: <CAFPFaMJ1opg7=SZ2ovFiAqjO_z1avpcNPFWTOoOqjhptoxSvcg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Define proper semantics for range() function
From: mark@demon-angel.eu (Mark Baker)

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