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

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]

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

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

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