# [RFC][VOTE] Strict Argument Count On Function Calls

- Thread: https://externals.io/message/84792
- Original archive: https://news-web.php.net/php.internals/84792
- Started by Marcio Almada on 2015-03-14T23:54:41+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #84792 — Marcio Almada — 2015-03-14T23:54:41+00:00

URL: https://externals.io/message/84792#84792

Hi,

The "Strict Argument Count" RFC is now on voting phase:

RFC: https://wiki.php.net/rfc/strict_argcount
PR: https://github.com/php/php-src/pull/1108

The voting will close in exactly 14 days counting from now (using the
date/time from this email as a reference).

If you have any doubt about what was already discussed, please refer to
this aggregated markmail summary http://markmail.org/thread/ol5s2vhw35ac2px3

Please read the RFC with full attention and good voting! :)

Thanks,
Márcio

---

## #84802 — Marcio Almada — 2015-03-15T06:59:26+00:00

URL: https://externals.io/message/84792#84802 · In reply to: #84792

Hi,

I received some requests to update the RFC with more information about BC
breaks + possible minor adjustments regarding dynamic function calls. So I
decided to drop the current voting, while it's still on the beginning, to
properly update the RFC. We had 7 votes computed - 4 "yes" and 3 "no" votes.

If you already voted, don't worry, it's just some minor changes and the
voting will be restarted by the end of the day (March 15) so we don't loose
the schedule. Another email will follow with a summary of what changed.

Thanks for the comprehension.

2015-03-14 20:54 GMT-03:00 Marcio Almada <marcio.web2@gmail.com>:

> Hi,
>
> The "Strict Argument Count" RFC is now on voting phase:
>
> RFC: https://wiki.php.net/rfc/strict_argcount
> PR: https://github.com/php/php-src/pull/1108
>
> The voting will close in exactly 14 days counting from now (using the
> date/time from this email as a reference).
>
> If you have any doubt about what was already discussed, please refer to
> this aggregated markmail summary
> http://markmail.org/thread/ol5s2vhw35ac2px3
>
> Please read the RFC with full attention and good voting! :)
>
> Thanks,
> Márcio

---

## #84820 — Dan Ackroyd — 2015-03-15T11:33:02+00:00

URL: https://externals.io/message/84792#84820 · In reply to: #84802

> Hi,
>
> I received some requests to update the RFC with more information about BC
> breaks + possible minor adjustments regarding dynamic function calls.


Please can you stop abusing the RFC process?

This RFC is attempting to change the language. You received the
information about the BC breaks weeks ago, they aren't new items that
you just heard about for the first time today.. You opened the voting
and then closed it immediately when you realised the vote wasn't going
to sail through.

You're now making changes to the RFC and proposing to re-open voting
on the same day. How are people meant to have time to read and think
about the changes?

It's also going to be impossible for people to try the patch out, or
to measure it for performance hit.

The problem this RFC fixes is not a big enough problem to justify
making decisions about the language at the last minute, particularly
as the last version of the RFC I read breaks a whole load of valid
code.

cheers
Dan

---

## #84879 — Marcio Almada — 2015-03-15T19:19:37+00:00

URL: https://externals.io/message/84792#84879 · In reply to: #84820

Hi

2015-03-15 8:33 GMT-03:00 Dan Ackroyd <danack@basereality.com>:

> 
> > […]
>
>
> Please can you stop abusing the RFC process?
>
> This RFC is attempting to change the language. You received the
> information about the BC breaks weeks ago, they aren't new items that
> you just heard about for the first time today.. You opened the voting
> and then closed it immediately when you realised the vote wasn't going
> to sail through.
>
>
There is no abuse. This is not true, I truly received a suggestion from Bob
Weiland and decided to consider it.
4:3 is not a sign that a voting will pass or not, it's only 7 votes and we
usually get ~52 votes during
a 14 days voting period.


> You're now making changes to the RFC and proposing to re-open voting
> on the same day. How are people meant to have time to read and think
> about the changes?
>
>
It's a **minor** change, as said before. This was the most prudent attitude.


> It's also going to be impossible for people to try the patch out, or
> to measure it for performance hit.
>
>
Performance has never been an issue with this RFC. You probably meant "bc
break" not "performance hit", and the suggested change about dynamic calls
Bob did, if accepted by, is a minor change that will actually reduce the BC
breaks not enlarge it.


> The problem this RFC fixes is not a big enough problem to justify
> making decisions about the language at the last minute, particularly
> as the last version of the RFC I read breaks a whole load of valid
> code.
>
>
A lot of people tell me the opposite. I listened to your opinion many times
and disagreed with it.
Please don't express your disagreement with the RFC by mixing it with false
accusations towards me.
There is a huge gap between both attitudes.

The disagreement is ok, but the false accusations coming from you make me
sad.


> cheers
> Dan
>

Marcio

---

## #85048 — Dan Ackroyd — 2015-03-16T12:41:03+00:00

URL: https://externals.io/message/84792#85048 · In reply to: #84879

> Hi
> > […]
>
> Performance has never been an issue with this RFC. You probably meant "bc
> break" not "performance hit", and the suggested change about dynamic calls
> Bob did, if accepted by, is a minor change that will actually reduce the BC
> breaks not enlarge it.


The patch has a pretty major bug in it.

If the function is called dynamically first, and then called
statically the warning is not given. i.e. the code below gives an
error 50% of the time. This is why people need time to evaluate code,
and why opening a vote straight after you've made a change to how the
syntax works is really bad idea.

<?php

function bar($x) {
}

if (rand(0, 1)) {
    $fn = 'bar';
    $fn(4, 5);
}
bar(4, 5);

exit(0);

?>

This was built off your branch with commit
6ca9d912c9aa8361852e979c172e57b011b91c16

cheers
Dan

---

## #85075 — Marcio Almada — 2015-03-16T17:04:46+00:00

URL: https://externals.io/message/84792#85075 · In reply to: #84792

Hi,

I had no time to reply all emails since yesterday, but right now we are
having a voting with 2 "yes" votes vs 16 "no" votes.

I think we all agree that the RFC won't pass and I'm withdrawing the RFC
for the following reasons:

   1. The sooner we end the voting period the better for the PHP time line.
   Since there is no motives to think the voting will flip, the best attitude
   seems to be a withdraw.
   2. We are having a lot of simultaneous voting right now and some voters
   care to read all the RFCs. The proposed RFC is long, requires testing etc.
   As it was already rejected, removing it from the list of RFCs in voting
   phase might be beneficial to the voting process as it reduces the RFC
   overload we are having because of the feature freeze.
   3. Looking at the ML, there are many controversial points that were
   raised, a lot of them since yesterday. Weather they are debatable or not,
   all this controversy during voting phases is a bad thing (look at the
   scalar type hints drama we had). So it's better to just put this to end and
   move on.

Thanks for the votes, I'll try to reply to the emails anyway whenever
necessary :)
PS: I don't intend to propose this RFC again in the future as I already
have other more important RFCs planned for PHP 7.1

Thanks,
Márcio

---

## #85116 — Simon Schick — 2015-03-17T08:20:52+00:00

URL: https://externals.io/message/84792#85116 · In reply to: #85075

Hi, all

At first, Thanks for all your work put in here, Marcio. It gave me a new
hint for a possible code-failure.

FYI: PhpStorm lately added an inspector for that. Glad to see that move
after I heard that the RFC won't pass.
https://youtrack.jetbrains.com/issue/WI-14692

Bye,
Simon

On Mon, Mar 16, 2015 at 6:04 PM, Marcio Almada <marcio.web2@gmail.com>
wrote:

> Hi,
>
> I had no time to reply all emails since yesterday, but right now we are
> having a voting with 2 "yes" votes vs 16 "no" votes.
>
> I think we all agree that the RFC won't pass and I'm withdrawing the RFC
> for the following reasons:
>
>    1. The sooner we end the voting period the better for the PHP time line.
>    Since there is no motives to think the voting will flip, the best
> attitude
>    seems to be a withdraw.
>    2. We are having a lot of simultaneous voting right now and some voters
>    care to read all the RFCs. The proposed RFC is long, requires testing
> etc.
>    As it was already rejected, removing it from the list of RFCs in voting
>    phase might be beneficial to the voting process as it reduces the RFC
>    overload we are having because of the feature freeze.
>    3. Looking at the ML, there are many controversial points that were
>    raised, a lot of them since yesterday. Weather they are debatable or
> not,
>    all this controversy during voting phases is a bad thing (look at the
>    scalar type hints drama we had). So it's better to just put this to end
> and
>    move on.
>
> Thanks for the votes, I'll try to reply to the emails anyway whenever
> necessary :)
> PS: I don't intend to propose this RFC again in the future as I already
> have other more important RFCs planned for PHP 7.1
>
> Thanks,
> Márcio

---

## #85520 — Pascal Martin — 2015-03-28T20:08:57+00:00

URL: https://externals.io/message/84792#85520 · In reply to: #85075

Le 16/03/2015 18:04, Marcio Almada a écrit :
> I had no time to reply all emails since yesterday, but right now we are
> having a voting with 2 "yes" votes vs 16 "no" votes.
>
> I think we all agree that the RFC won't pass and I'm withdrawing the RFC

Hi,

Even though it's a bit too late: thanks for your work on this!

At AFUP, we were +1 (by a rather large margin) on the idea of checking 
for additional arguments, considering it would help detect some 
(possible) future bugs. Seems we were going on the opposite direction of 
the votes on the RFC itself.

We didn't quite reach a consensus between notices and warnings, though 
-- mostly because they would *maybe* have helped detect *possible 
future* bugs.

-- 
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/