Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function
On Thu, 1 Jun 2023 at 17:16, G. P. B. wrote: > 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
Re: [PHP-DEV] [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 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 range(1, 5, 2.1) // list
In my opinion, no matter, if start, end or step is a float the result
should be a list.
A list is compatible and interpretable as a list 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function
On Thu, 8 Jun 2023 at 07:35, Marc 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 range(1, 5, 2.1) // list
>
> In my opinion, no matter, if start, end or step is a float the result
> should be a list.
>
A list is compatible and interpretable as a list 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
Re: [PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function
On 01.06.23 18:16, G. P. B. wrote:
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 range(1, 5, 2.1) // list
In my opinion, no matter, if start, end or step is a float the result
should be a list.
Thanks,
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
