Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [VOTE] Arrays starting with a negative index »

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

php.internals

Pedro Magalhães

9 years ago
Hi all, I have just opened the vote on this RFC. The main goal of the RFC is to eliminate the inconsistency in arrays when negative numeric keys are used explicitly and the following implicit keys will start from zero. You can find the RFC here: https://wiki.php.net/rfc/negative_array_index The previous discussion: https://externals.io/thread/712 And the PR (also some discussion): https://github.com/php/php-src/pull/2383 Voting is open from now until 20/6/2017 18:00 UTC. Regards, Pedro

Derick Rethans

9 years ago
On Tue, 6 Jun 2017, Pedro Magalhães wrote:
> Hi all, > > I have just opened the vote on this RFC. > > The main goal of the RFC is to eliminate the inconsistency in arrays when > negative numeric keys are used explicitly and the following implicit keys > will start from zero. > > You can find the RFC here: https://wiki.php.net/rfc/negative_array_index > The previous discussion: https://externals.io/thread/712 > And the PR (also some discussion): https://github.com/php/php-src/pull/2383
I voted no because of the BC break. cheers, Derick

François Laupretre

9 years ago
Hi, The same for me. Strange to see 7 people willing to introduce such a BC break in a minor version, or did I miss something ? Anyway, +1 to introduce the change in PHP 8. Cheers, François Le 07/06/2017 à 13:31, Derick Rethans a écrit :

Marco Pivetta

9 years ago
Voting "no" as well, since applications relying on "array_keys()" and assuming on the allowed integer range of those may even become vulnerable. This is one of those subtle BC breaks that are extremely hard to find. On 7 Jun 2017 2:12 p.m., "François Laupretre" <francois@tekwire.net> wrote:

Sebastian Bergmann

9 years ago
Am 07.06.2017 um 13:31 schrieb Derick Rethans:
> I voted no because of the BC break.
Same.

Aaron Piotrowski

9 years ago
> On Jun 7, 2017, at 6:31 AM, Derick Rethans <derick@php.net> wrote: > > I voted no because of the BC break. >
Changed my vote to no for the same reason. The subtly of the BC would make bugs potentially difficult to discern. Would happily vote yes again for an RFC targeting 8. Aaron Piotrowski

Christoph Becker

9 years ago
On 06.06.2017 at 19:55, Pedro Magalhães wrote:
> Hi all, > > I have just opened the vote on this RFC. > > The main goal of the RFC is to eliminate the inconsistency in arrays when > negative numeric keys are used explicitly and the following implicit keys > will start from zero. > > You can find the RFC here: https://wiki.php.net/rfc/negative_array_index > The previous discussion: https://externals.io/thread/712 > And the PR (also some discussion): https://github.com/php/php-src/pull/2383 > > Voting is open from now until 20/6/2017 18:00 UTC.
I don't think that the current behavior makes much sense, but since it is well documented and it isn't a bug, changing it in a minor version wouldn't comply to our release process[1]. Therefore, I've voted against, but I'd be happy to see this improvement in PHP 8. [1] <https://wiki.php.net/rfc/releaseprocess#releases_cycle>
-- Christoph M. Becker

François Laupretre

9 years ago
Hi, Right. Introducing this change is not compatible with the release process, whatever the result of the vote. So, I respectfully ask you to change target to PHP 8 or explain why we should make an exception to the process. Reasons you gave so far are OK for a major version, but not for a minor one. This is not against you or your work, as I'd also like to change such inconsistent behavior, but the probability of BC break is too high, IMO. Regards François Le 07/06/2017 à 14:19, Christoph M. Becker a écrit :

Dan Ackroyd

9 years ago
On 7 June 2017 at 13:41, François Laupretre <francois@tekwire.net> wrote:
> Hi, > > Right. Introducing this change is not compatible with the release process, > whatever the result of the vote... explain why we > should make an exception to the process.
The RFC process is the way that we change the rules, and RFCs are not constrained by any previous RFC or by any 'constitution' as PHP doesn't have one. This is similar to how the UK parliament isn't constrained by any previous decision or constitution, which is different from most other countries, where the power of the government is limited by constitution. It behooves people to pay attention to RFCs announced on this list, and to raise their concerns during the comment phase - not to ask for "why is this is being allowed" only when the voting starts. To be clear, I'm referring to some of the more dramatic twitter communications rather than any emails to this list. Also, I'd be more comfortable with this targeting PHP 8 - though I'm hoping someone would demonstrate some actual code that will break, which would make it easier to decide, rather than just people claiming stuff might break. cheers Dan

Rowan Collins

9 years ago
On 7 June 2017 14:32:50 BST, Dan Ackroyd <danack@basereality.com> wrote:
>The RFC process is the way that we change the rules, and RFCs are not >constrained by any previous RFC or by any 'constitution' as PHP >doesn't have one. This is similar to how the UK parliament isn't >constrained by any previous decision or constitution, which is >different from most other countries, where the power of the government >is limited by constitution.
Even without a written constitution, you can't simply pass something that *incidentally* changes a pre-established rule, you have to explicitly make an exception or a new rule. To take the analogy of English Law, if two Acts conflicted without mentioning each other, I don't think it would be a foregone conclusion that the newer law should be followed. What's more, there are laws that explicitly constrain the process of passing other laws - the Parliament Acts, for instance, or the Human Rights Act. If you can simply say "this conflicts with our agreed procedures, but it's newer, so the procedures are automatically wrong" then you might as well not have any procedures. Saying "this is an acceptable exception to normal procedures because..." seems a reasonable minimum requirement. Regards,
-- Rowan Collins [IMSoP]

Pedro Magalhães

9 years ago
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> you can't simply pass something that *incidentally* changes a > pre-established rule
Hi Rowan, Would you consider that that is not the case for your own RFC? https://wiki.php.net/rfc/deprecate-bareword-strings

Rowan Collins

9 years ago
On 7 June 2017 15:23:13 BST, "Pedro Magalhães" <mail@pmmaga.net> wrote:
>On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins <rowan.collins@gmail.com> >wrote: > >> you can't simply pass something that *incidentally* changes a >> pre-established rule > > >Hi Rowan, > >Would you consider that that is not the case for your own RFC? >https://wiki.php.net/rfc/deprecate-bareword-strings
I'm sorry, I don't follow. What rule is broken, incidentally or explicitly, by that RFC?
-- Rowan Collins [IMSoP]

Pedro Magalhães

9 years ago
On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 7 June 2017 15:23:13 BST, "Pedro Magalhães" <mail@pmmaga.net> wrote: > >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins <rowan.collins@gmail.com> > >wrote: > > > >> you can't simply pass something that *incidentally* changes a > >> pre-established rule > > > > > >Hi Rowan, > > > >Would you consider that that is not the case for your own RFC? > >https://wiki.php.net/rfc/deprecate-bareword-strings > > > I'm sorry, I don't follow. What rule is broken, incidentally or > explicitly, by that RFC? > > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
The page that was already mentioned on this thread: https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly states the following: x.y.z to x.y+1.z
> Backward compatibility must be kept
However, a number of already implemented RFCs for 7.2 do not follow that rule strictly: - https://wiki.php.net/rfc/number_format_negative_zero - https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts - https://wiki.php.net/rfc/deprecate-bareword-strings - https://wiki.php.net/rfc/get_class_disallow_null_parameter - https://wiki.php.net/rfc/counting_non_countables - https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp - https://wiki.php.net/rfc/hash-context.as-resource - https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003 - As well as some of the RFCs still pending implementation I don't mean at all that these should not have been accepted. Especially the ones that initiate a deprecation phase. But it is seems to me that this RFC does not break any rule that has been upheld strictly up to this point. Regards, Pedro

Rowan Collins

9 years ago
On 7 June 2017 17:36:01 BST, "Pedro Magalhães" <mail@pmmaga.net> wrote:
>On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins <rowan.collins@gmail.com> >wrote: > >> On 7 June 2017 15:23:13 BST, "Pedro Magalhães" <mail@pmmaga.net> >wrote: >> >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins ><rowan.collins@gmail.com> >> >wrote: >> > >> >> you can't simply pass something that *incidentally* changes a >> >> pre-established rule >> > >> > >> >Hi Rowan, >> > >> >Would you consider that that is not the case for your own RFC? >> >https://wiki.php.net/rfc/deprecate-bareword-strings >> >> >> I'm sorry, I don't follow. What rule is broken, incidentally or >> explicitly, by that RFC? >> > >The page that was already mentioned on this thread: >https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly >states >the following: > >x.y.z to x.y+1.z >> Backward compatibility must be kept > > >However, a number of already implemented RFCs for 7.2 do not follow >that >rule strictly:
...
>I don't mean at all that these should not have been accepted. >Especially >the ones that initiate a deprecation phase.
Deprecating something is basically the opposite of breaking backwards compatibility in a minor release. The entire point of deprecation messages is to indicate ahead of time that something will be broken later, but not break it yet. Unless you're being purposefully pedantic to try and prove that black is white, adding any log message is barely even a functional change, let alone a breaking one. That said, there *are* sometimes RFCs that break the rule. Usually, they get feedback regarding the break, just as this one is. Often, they attempt to justify an exception to the rule, as I and others have suggested this one could. I don't always agree with the way those exceptions are applied (too_few_args was one I opposed, for instance). I hope you can see that saying "well, we allow people to fix spelling mistakes in error messages, so we might as well allow changes that completely change the behaviour of a core function" is pretty ridiculous. We have a rule, there are grey areas, and we try to navigate them; in this case, people are saying the RFC has fallen the wrong side of that grey area. If you disagree, feel free to comment on this specific case. Regards,
-- Rowan Collins [IMSoP]

lists@rhsoft.net

9 years ago
Am 07.06.2017 um 16:23 schrieb Pedro Magalhães:
> On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins <rowan.collins@gmail.com> > wrote: > >> you can't simply pass something that *incidentally* changes a >> pre-established rule > > > Hi Rowan, > > Would you consider that that is not the case for your own RFC? > https://wiki.php.net/rfc/deprecate-bareword-strings
have you seen any valid uecase for that in the past 15 years which was not a typo in a constant name or forgotten quotes?

Christoph Becker

9 years ago
On 07.06.2017 at 15:32, Dan Ackroyd wrote:
> On 7 June 2017 at 13:41, François Laupretre <francois@tekwire.net> wrote: > >> Right. Introducing this change is not compatible with the release process, >> whatever the result of the vote... explain why we >> should make an exception to the process. > > The RFC process is the way that we change the rules, and RFCs are not > constrained by any previous RFC […]
If that was so, we wouldn't even be bound to the "Voting on PHP features" RFC[1], which wouldn't make sense, IMHO. [1] <https://wiki.php.net/rfc/voting>
-- Christoph M. Becker

Pedro Magalhães

9 years ago
On Wed, Jun 7, 2017 at 2:41 PM, François Laupretre <francois@tekwire.net> wrote:
> > So, I respectfully ask you to change target to PHP 8 or explain why we > should make an exception to the process. Reasons you gave so far are OK for > a major version, but not for a minor one. This is not against you or your > work, as I'd also like to change such inconsistent behavior, but the > probability of BC break is too high, IMO. >
I will not change the target version now during the voting phase. Also because it wouldn't make sense to vote for a feature for 8.0 yet. If the RFC is rejected and the sentiment is that most people would agree with the change but not with the timing, I will propose it again when RFCs for 8.0 are relevant. Thanks, Pedro

Fleshgrinder

9 years ago
On 6/7/2017 8:23 PM, Pedro Magalhães wrote:
> I will not change the target version now during the voting phase. Also > because it wouldn't make sense to vote for a feature for 8.0 yet. If the > RFC is rejected and the sentiment is that most people would agree with the > change but not with the timing, I will propose it again when RFCs for 8.0 > are relevant. > > Thanks, > Pedro >
It does not loose relevance just because the implementation is postponed. On the contrary, we could directly start advertising that change, which is super useful to the PHP ecosystem because they can prepare their code for the change. The change you are proposing is absolutely necessary, and it is a great initiative of yours! :) However, the possibility of introducing this kind of change in a minor is dangerous. I am usually against almost all of these changes, but in favor of deprecation to fix more of these unexpected features.
-- Richard "Fleshgrinder" Fussenegger

François Laupretre

9 years ago
Hi Pedro, Le 07/06/2017 à 20:23, Pedro Magalhães a écrit :
> I will not change the target version now during the voting phase. Also > because it wouldn't make sense to vote for a feature for 8.0 yet. If the > RFC is rejected and the sentiment is that most people would agree with > the change but not with the timing, I will propose it again when RFCs > for 8.0 are relevant.
I am sorry you take it this way. Voting today on a feature for 8.0 wouldn't be ridiculous and it would make me change my vote, as most others. Instead of nonsense, it would be a sign of maturity for the PHP project. It would be great, IMO, to open a 'Approved for 8.0' section on the RFC page now, and your RFC could proudly be the 1st one to enter it. This would prove, IMO again, that we are finally able to think more long term than we did in the past. The most interesting proposals for 7.0 were rejected before it was too late to introduce such disruptive changes. They should have been prepared a long time before, introducing a compatibility path, so that people could prepare their code. This was also one of the reasons for the failure of PHP 6. So, advertising a future BC break months before a release perfectly makes sense. The only risk would be to forget it but, by creating a specific section on the RFC page, we ensure it won't. In theory, it should even work this way : gather proposals, vote, feature freeze, implements PRs, merge them, and, only at this time, start publishing alpha, beta, RC, final. We accept changes after publishing alpha because most people wake up too late. So, I encourage you again to initiate a much more mature way of planning the next major version ! Regards François

Rowan Collins

9 years ago
On 8 June 2017 08:52:41 BST, "François Laupretre" <francois@php.net> wrote:
> It would be great, IMO, to open a 'Approved for 8.0' section >on >the RFC page now, and your RFC could proudly be the 1st one to enter >it.
I definitely agree with this, as I've argued before for a more timeline based approach to major releases to avoid / reduce a repeat of the "quick, while 7.0 is on the table" RFC rush, and the "well, 7.1 is still kinda the beginning of 7.x, so we can break things a little" kludges. There is still the question of how to ease the transition, though: a subtle break documented years in advance is still a subtle break, so we need to think what form of deprecation is useful to developers. That means more than restarting voting with a new target version, and if the final target is 8.0, there's no rush to hold that new vote. Regards,
-- Rowan Collins [IMSoP]

Christoph Becker

9 years ago
On 10.06.2017 at 21:29, Rowan Collins wrote:
> On 8 June 2017 08:52:41 BST, "François Laupretre" <francois@php.net> wrote: >> It would be great, IMO, to open a 'Approved for 8.0' section >> on >> the RFC page now, and your RFC could proudly be the 1st one to enter >> it. > > I definitely agree with this, as I've argued before for a more timeline based approach to major releases to avoid / reduce a repeat of the "quick, while 7.0 is on the table" RFC rush, and the "well, 7.1 is still kinda the beginning of 7.x, so we can break things a little" kludges.
I second that. Consider, for instance, the "Deprecate and remove INTL_IDNA_VARIANT_2003" RFC[1]. It has been decided to change the default of idn_to_*() to INTL_IDNA_VARIANT_UTS46 as of PHP 7.4. But what if there will not even be a PHP 7.4? Also it has been decided to remove support for INTL_IDNA_VARIANT_2003 as of PHP 8.0. What if there will be a PHP 7.42 – would we have to wait for decades to remove INTL_IDNA_VARIANT_2003 support? [1] <https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003>
-- Christoph M. Becker

Pedro Magalhães

9 years ago
On Thu, Jun 8, 2017 at 9:52 AM, François Laupretre <francois@php.net> wrote:
> > I am sorry you take it this way. Voting today on a feature for 8.0 > wouldn't be ridiculous and it would make me change my vote, as most others. > Instead of nonsense, it would be a sign of maturity for the PHP project. It > would be great, IMO, to open a 'Approved for 8.0' section on the RFC page > now, and your RFC could proudly be the 1st one to enter it. >
I agree with your suggestion and general sentiment so I propose to do the following: - The current voting widget refers to introducing the change on 7.2. (Will be mentioned on the RFC page) - Add a new voting widget for introducing the change on 8.0. - Extend the voting period for one more week than originally planned until 27/6/2017 18:00 UTC. Additionally, since some people also mentioned the difficulty in detecting this change, if the vote for 8.0 passes, I suggest to introduce a E_DEPRECATED notice where the implicit keys will change. You can see that implementation here: https://github.com/php/php-src/compare/master...pmmaga:negative-array-deprecated Would it make sense to include an extra voting widget for the introduction of the notice? Given that we are on the voting phase I would oppose changing anything by principle, but given that most of the discussion on the topic only started when the vote was started and what is dividing the vote is the timing, I think it makes sense to update the RFC in this case. Let me know what you think. Thanks, Pedro

Davey

9 years ago
Pedro, It would be best to just kill the vote and start over. The proposal should be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should be one vote, as doing both together should be the only option. - Davey On Sun, Jun 11, 2017 at 8:25 AM, Pedro Magalhães <mail@pmmaga.net> wrote:

Sebastian Bergmann

9 years ago
Am 12.06.2017 um 08:14 schrieb Davey Shafik:
> It would be best to just kill the vote and start over. The proposal should > be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should > be one vote, as doing both together should be the only option.
+1