Everything

php

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

php.internals

Pedro Magalhães

8 years ago

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

Pedro Magalhães

8 years ago

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

Niklas Keller

8 years ago

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>:

Pedro Magalhães

8 years ago

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

Nikita Popov

8 years ago

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

Pedro Magalhães

8 years ago

On Mon, Feb 26, 2018 at 1:05 PM, Nikita Popov <nikita.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

Pedro Magalhães

8 years ago

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