Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index

Posted by Pedro Magalhães 
Pedro Magalhães
[PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index
February 13, 2018 09:10PM
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
On Tue, Feb 13, 2018 at 8:03 PM, Pedro Magalhães <[email protected]> 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
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 <[email protected]>:
> On Tue, Feb 13, 2018 at 8:03 PM, Pedro Magalhães <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Niklas,

On Thu, Feb 22, 2018 at 8:38 PM, Niklas Keller <[email protected]> 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
On Tue, Feb 13, 2018 at 9:03 PM, Pedro Magalhães <[email protected]> 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
On Mon, Feb 26, 2018 at 1:05 PM, Nikita Popov <[email protected]> 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
On Mon, Feb 26, 2018 at 5:25 PM, Pedro Magalhães <[email protected]> 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
Sorry, only registered users may post in this forum.

Click here to login