[RFC] [VOTE] Define proper semantics for range() function View as Markdown

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.

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

Marc