# [RFC] [Discussion] Arrays starting with a negative index - Thread: https://externals.io/message/101861 - Original archive: https://news-web.php.net/php.internals/101861 - Started by mail@pmmaga.net on 2018-02-13T20:03:16+00:00 - Messages: 7 - RFC: Arrays starting with a negative index (Implemented (PHP 8.0)) — https://externals.io/rfc/negative_array_index.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #101861 — mail@pmmaga.net — 2018-02-13T20:03:16+00:00 URL: https://externals.io/message/101861#101861 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 --- ## #101900 — mail@pmmaga.net — 2018-02-22T17:38:11+00:00 URL: https://externals.io/message/101861#101900 · In reply to: #101861 > 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'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 --- ## #101902 — Niklas Keller — 2018-02-22T20:38:11+00:00 URL: https://externals.io/message/101861#101902 · In reply to: #101900 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_DEPRECATED` notice 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 : > > > > […] > > 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 --- ## #101903 — mail@pmmaga.net — 2018-02-22T21:17:18+00:00 URL: https://externals.io/message/101861#101903 · In reply to: #101902 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_DEPRECATED` notice 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 --- ## #101931 — Nikita Popov — 2018-02-26T13:05:24+00:00 URL: https://externals.io/message/101861#101931 · In reply to: #101861 > 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 > 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 --- ## #101935 — mail@pmmaga.net — 2018-02-26T17:25:37+00:00 URL: https://externals.io/message/101861#101935 · In reply to: #101931 > > > 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 > > […] > 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 --- ## #101939 — mail@pmmaga.net — 2018-02-28T17:52:15+00:00 URL: https://externals.io/message/101861#101939 · In reply to: #101935 > > 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