# [RFC] [VOTE] Define proper semantics for range() function

- Thread: https://externals.io/message/120501
- Original archive: https://news-web.php.net/php.internals/120501
- Started by G. P. B. on 2023-06-01T16:16:49+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #120501 — G. P. B. — 2023-06-01T16:16:49+00:00

URL: https://externals.io/message/120501#120501

Hello internals,

The vote for the Define proper semantics for `range()` function RFC is now
open and will last for two weeks until the 15th of June 2023:

https://wiki.php.net/rfc/proper-range-semantics

Best regards,

George P. Banyard

---

## #120538 — Marc — 2023-06-08T06:35:00+00:00

URL: https://externals.io/message/120501#120538 · In reply to: #120501

> Hello internals,
>
> The vote for the Define proper semantics for `range()` function RFC is now
> open and will last for two weeks until the 15th of June 2023:
>
> https://wiki.php.net/rfc/proper-range-semantics
>
> Best regards,
>
> George P. Banyard
>
Hi George,

sorry for speaking up so late but I think the following change is a 
mistake and unexpected:

 > Calls to `range()` that have integer boundaries but a float step that 
is compatible as an integer will now return an array of integers instead 
of an array of floats:

var_dump( range(1, 5, 2.0) );
/* New Behaviour */
array(3) {
   [0]=>
   int(1)
   [1]=>
   int(3)
   [2]=>
   int(5)
}
/* Current Behaviour */
array(3) {
   [0]=>
   float(1)
   [1]=>
   float(3)
   [2]=>
   float(5)
}

The problem I see with this is that the return type changes from float 
to int "magically" based on the value of the step.
range(1, 5, 2.0) // list<int> range(1, 5, 2.1) // list<float>

In my opinion, no matter, if start, end or step is a float the result 
should be a list<float>.

Thanks,

Marc

---

## #120540 — G. P. B. — 2023-06-08T11:16:18+00:00

URL: https://externals.io/message/120501#120540 · In reply to: #120538

> sorry for speaking up so late but I think the following change is a
> mistake and unexpected:
>
> > […]
> is compatible as an integer will now return an array of integers instead
> of an array of floats:
>
> var_dump( range(1, 5, 2.0) );
> /* New Behaviour */
> array(3) {
>    [0]=>
>    int(1)
>    [1]=>
>    int(3)
>    [2]=>
>    int(5)
> }
> /* Current Behaviour */
> array(3) {
>    [0]=>
>    float(1)
>    [1]=>
>    float(3)
>    [2]=>
>    float(5)
> }
>
> The problem I see with this is that the return type changes from float
> to int "magically" based on the value of the step.
> range(1, 5, 2.0) // list<int> range(1, 5, 2.1) // list<float>
>
> In my opinion, no matter, if start, end or step is a float the result
> should be a list<float>.
>

A list<int> is compatible and interpretable as a list<float> so this only I
slight change in output and has effectively no BC break when using the
values generated by `range()`.
Moreover, this change is needed to make calls such as range("a", "z", 3.0)
work as intended.
I.e. generating a list of characters instead of generating the list [0.0]
by attempting to cast the strings to floats.

Moreover, considering the return type is already pretty magical, supporting
this specific case would add even more complexity to the implementation,
and this has effectively no BC break, I will not change this detail.
More so that the RFC is currently in voting and cannot be amended.

Best regards,

George P. Banyard

---

## #120543 — Marc — 2023-06-08T18:44:56+00:00

URL: https://externals.io/message/120501#120543 · In reply to: #120540

> 
>
> > […]
> A list<int> is compatible and interpretable as a list<float> so this only I
> slight change in output and has effectively no BC break when using the
> values generated by `range()`.
> Moreover, this change is needed to make calls such as range("a", "z", 3.0)
> work as intended.
> I.e. generating a list of characters instead of generating the list [0.0]
> by attempting to cast the strings to floats.
>
> Moreover, considering the return type is already pretty magical, supporting
> this specific case would add even more complexity to the implementation,
> and this has effectively no BC break, I will not change this detail.
> More so that the RFC is currently in voting and cannot be amended.

Thanks for your explanation. Now it makes more sense to me.

Marc

---

## #120587 — G. P. B. — 2023-06-15T14:47:40+00:00

URL: https://externals.io/message/120501#120587 · In reply to: #120501

> Hello internals,
>
> The vote for the Define proper semantics for `range()` function RFC is now
> open and will last for two weeks until the 15th of June 2023:
>
> https://wiki.php.net/rfc/proper-range-semantics
>

The vote has now ended with 20 votes in favour and 0 against.

Best regards,

George P. Banyard