Hi internals,
I want to bring up this RFC once again given that now seems to be the right
timing for it. I have previously canceled the vote when I initially
proposed this to land on 7.2 which was seen as too big of a BC for a minor
version. On a second attempt targeting 8.0 I have also canceled the vote as
the inclusion of a deprecation notice in cases where the behavior will
change warranted further discussion.
To address these issues, the current version of the RFC will have 2
separate votes:
- Introduce the new behavior on 8.0
- Introduce a deprecation notice on 7.3
For those not familiar with the RFC, the general idea is that currently,
any array that has a number n as it's first numeric key will have for it's
next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
make this consistent by always using n+1 regardless of the sign of n.
In code:
$a[-2] = true; // Current: Key is -2, RFC: Key is -2
$a[] = true; // Current: Key is 0, RFC: Key is -1
$a[] = true; // Current: Key is 1, RFC: Key is 0
I invite you to read the full RFC:
https://wiki.php.net/rfc/negative_array_index and bring up any issues you
see with the current version before the voting period starts.
Looking forward for any feedback.
Regards,
Pedro Magalhães
Hi internals,
I want to bring up this RFC once again given that now seems to be the
right timing for it. I have previously canceled the vote when I initially
proposed this to land on 7.2 which was seen as too big of a BC for a minor
version. On a second attempt targeting 8.0 I have also canceled the vote as
the inclusion of a deprecation notice in cases where the behavior will
change warranted further discussion.To address these issues, the current version of the RFC will have 2
separate votes:
- Introduce the new behavior on 8.0
- Introduce a deprecation notice on 7.3
For those not familiar with the RFC, the general idea is that currently,
any array that has a number n as it's first numeric key will have for it's
next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
make this consistent by always using n+1 regardless of the sign of n.
In code:
$a[-2] = true; // Current: Key is -2, RFC: Key is -2
$a[] = true; // Current: Key is 0, RFC: Key is -1
$a[] = true; // Current: Key is 1, RFC: Key is 0I invite you to read the full RFC: https://wiki.php.net/rfc/
negative_array_index and bring up any issues you see with the current
version before the voting period starts.Looking forward for any feedback.
Regards,
Pedro Magalhães
Hi internals,
I'd like to open the voting for this RFC in 5 days (27/2).
Please bring up any feedback you may have about it before the voting period
starts.
Thanks in advance,
Pedro Magalhães
Hey,
"Will no longer produce any output." in the BC example is wrong, it
will produce a notice due to an undefined index then.
NOTE: If accepted, during the deprecation phase the following
E_DEPRECATEDnotice would be emitted in cases where the behavior will change:
I guess that means also $a[-3] = true; $a[] = false; will emit a
deprecation notice?
Regards, Niklas
2018-02-22 18:38 GMT+01:00 Pedro Magalhães mail@pmmaga.net:
Hi internals,
I want to bring up this RFC once again given that now seems to be the
right timing for it. I have previously canceled the vote when I initially
proposed this to land on 7.2 which was seen as too big of a BC for a minor
version. On a second attempt targeting 8.0 I have also canceled the vote as
the inclusion of a deprecation notice in cases where the behavior will
change warranted further discussion.To address these issues, the current version of the RFC will have 2
separate votes:
- Introduce the new behavior on 8.0
- Introduce a deprecation notice on 7.3
For those not familiar with the RFC, the general idea is that currently,
any array that has a number n as it's first numeric key will have for it's
next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
make this consistent by always using n+1 regardless of the sign of n.
In code:
$a[-2] = true; // Current: Key is -2, RFC: Key is -2
$a[] = true; // Current: Key is 0, RFC: Key is -1
$a[] = true; // Current: Key is 1, RFC: Key is 0I invite you to read the full RFC: https://wiki.php.net/rfc/
negative_array_index and bring up any issues you see with the current
version before the voting period starts.Looking forward for any feedback.
Regards,
Pedro MagalhãesHi internals,
I'd like to open the voting for this RFC in 5 days (27/2).
Please bring up any feedback you may have about it before the voting period
starts.Thanks in advance,
Pedro Magalhães
Hi Niklas,
Hey,
"Will no longer produce any output." in the BC example is wrong, it
will produce a notice due to an undefined index then.
That's right. I've updated the RFC to make that section more clear.
Including that the example would also emit the deprecation notice.
NOTE: If accepted, during the deprecation phase the following
E_DEPRECATEDnotice would be emitted in cases where the behavior will
change:I guess that means also $a[-3] = true; $a[] = false; will emit a
deprecation notice?
Yes, it would.
Thanks,
Pedro
Hi internals,
I want to bring up this RFC once again given that now seems to be the right
timing for it. I have previously canceled the vote when I initially
proposed this to land on 7.2 which was seen as too big of a BC for a minor
version. On a second attempt targeting 8.0 I have also canceled the vote as
the inclusion of a deprecation notice in cases where the behavior will
change warranted further discussion.To address these issues, the current version of the RFC will have 2
separate votes:
- Introduce the new behavior on 8.0
- Introduce a deprecation notice on 7.3
For those not familiar with the RFC, the general idea is that currently,
any array that has a number n as it's first numeric key will have for it's
next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
make this consistent by always using n+1 regardless of the sign of n.
In code:
$a[-2] = true; // Current: Key is -2, RFC: Key is -2
$a[] = true; // Current: Key is 0, RFC: Key is -1
$a[] = true; // Current: Key is 1, RFC: Key is 0I invite you to read the full RFC:
https://wiki.php.net/rfc/negative_array_index and bring up any issues you
see with the current version before the voting period starts.Looking forward for any feedback.
Regards,
Pedro Magalhães
I like the change, but I'm concerned about the technical impact that
deprecation notice will have. An error handler can convert the notice into
an exception, which means that zend_hash_next_index_insert is now going to
be a throwing operation. Apart from the fact that the currently linked
implementation is not exception-safe (if the deprecation notice throws, the
element is still inserted), it's quite likely that at least some of the
250 uses of zend_hash_next_index_insert will not deal with exceptions
correctly.
Nikita
I like the change, but I'm concerned about the technical impact that
deprecation notice will have. An error handler can convert the notice into
an exception, which means that zend_hash_next_index_insert is now going
to be a throwing operation. Apart from the fact that the currently linked
implementation is not exception-safe (if the deprecation notice throws, the
element is still inserted), it's quite likely that at least some of the250 uses of zend_hash_next_index_insert will not deal with exceptions
correctly.Nikita
Hi Nikita, thanks for the feedback.
About the implementation of the deprecation notice, I agree that it should
be updated to be exception-safe.
About the issue if it being dealt with correctly everywhere, I'm honestly
more inclined towards dealing with it when/if it becomes a problem. I think
the number of users that 1) Start an array with a negative number, 2) Use
implicit keys afterwards and 3) Promote Notices to Exceptions must be a
very very small subset. Would you consider this an acceptable approach for
this specific case?
Thanks,
Pedro
Hi Nikita, thanks for the feedback.
About the implementation of the deprecation notice, I agree that it should
be updated to be exception-safe.
Hi internals,
Just to give you an update on the current status. I'm still trying to solve
a few lasting issues on the PR with the deprecation notice which is why I
the voting hasn't started yet.
I'd prefer to have this all sorted out before the vote starts because if I
can't reach a stable solution for the deprecation notice, I prefer to just
not propose it at all.
Regards,
Pedro