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

On 08.06.23 13:16, G. P. B. wrote:

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.

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