Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119789
MIME-Version: 1.0
References: <CAFPFaMJ1opg7=SZ2ovFiAqjO_z1avpcNPFWTOoOqjhptoxSvcg@mail.gmail.com>
 <d445b78a-1df3-0b16-1e43-f7d92dd9103a@demon-angel.eu>
In-Reply-To: <d445b78a-1df3-0b16-1e43-f7d92dd9103a@demon-angel.eu>
Date: Thu, 30 Mar 2023 14:48:58 +0100
Message-ID: <CAFPFaMJwaXsuZQmK=xE7PKpVYs6Rp4CosKnqycr=kdU0qv1D2Q@mail.gmail.com>
To: Mark Baker <mark@demon-angel.eu>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000006a6ec705f81e5bc0"
Subject: Re: [PHP-DEV] [RFC] Define proper semantics for range() function
From: george.banyard@gmail.com ("G. P. B.")

--0000000000006a6ec705f81e5bc0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 30 Mar 2023 at 03:50, Mark Baker <mark@demon-angel.eu> wrote:

> On 28/03/2023 00:36, G. P. B. wrote:
> > Hello internals,
> >
> > While working on analysing the impact of the changes proposed by amendi=
ng
> > 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 bug=
s:
> > 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.


I still find it somewhat odd, but this is not a hill I'm going to die on.
I've changed the behaviour to throw a ValueError if a negative step is
provided with increasing range and accept negative steps for decreasing
ranges.
Furthermore, I've also made passing an empty string an E_WARNING with a
cast to 0, same as the current behaviour.

See new version:
https://wiki.php.net/rfc/proper-range-semantics


> 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.
>

Frankly I was also surprised that the behaviour with strings was to do an
ASCII code point increment.
As I would agree that range("Y", "AC") returning ["Y", "Z", "AA", "AB",
"AC"] would have been more intuitive than the silently discarding
everything past the 1st byte.
However, I don't think there is much point in breaking BC to return a
possible generator or fix the unfortunate string behaviour.
I would rather that PHP creates dedicated syntax to creates ranges (e.g.
$s..$e seems to be what most other programming languages settles on,
although it might be slightly confused as concatenation) =C3=A0 la Ruby whi=
ch
allows objects that implement certain methods to also be used to generate
ranges.
This is IMHO way more powerful as it would allow the creation of Date
ranges or other custom ranges.
And part of this proposal could be to support the aforementioned
alphabetical string ranges natively without needing to break BC on range()
and let this function just fade away into obscurity.

There is also this C++ talk from over a decade ago that argues that Ranges
are better than iterator, so this might be an additional motivation as to
why we would want this:
https://accu.org/conf-docs/PDFs_2009/AndreiAlexandrescu_iterators-must-go.p=
df


> 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.
>

Because I didn't think of this and was just well usual numeric string
behaviour or non-numeric string behaviour that truncates the string.
But that range('3c', '5e') is the only way to get an array of digits as
strings, and it makes me want to shout into the abyss.
I'm not sure it super worth to mention those cases, but I can add examples
of this to the RFC after crying about the even more insane behaviour
range() currently has.

Best regards,

George P. Banyard

--0000000000006a6ec705f81e5bc0--