[RFC] [Discussion] Arrays starting with a negative index

  101861
February 13, 2018 20:03 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
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
February 22, 2018 17:38 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
On Tue, Feb 13, 2018 at 8:03 PM, Pedro Magalhães <mail@pmmaga.net> wrote:

> 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
February 22, 2018 20:38 me@kelunik.com (Niklas Keller)
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 <mail@pmmaga.net>:
> On Tue, Feb 13, 2018 at 8:03 PM, Pedro Magalhães <mail@pmmaga.net> wrote: > >> 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
  101903
February 22, 2018 21:17 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
Hi Niklas,

On Thu, Feb 22, 2018 at 8:38 PM, Niklas Keller <me@kelunik.com> wrote:

> 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
February 26, 2018 13:05 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Feb 13, 2018 at 9:03 PM, Pedro Magalhães <mail@pmmaga.net> wrote:

> 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
February 26, 2018 17:25 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
On Mon, Feb 26, 2018 at 1:05 PM, Nikita Popov ppv@gmail.com> wrote:
> > > 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 >
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
February 28, 2018 17:52 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
On Mon, Feb 26, 2018 at 5:25 PM, Pedro Magalhães <mail@pmmaga.net> wrote:
> > 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