On Thu, 8 Jun 2023 at 07:35, Marc <marc@mabe.berlin> wrote:
> 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>.
>
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
