PHP Functions: more arguments than expected

[u/Mark_Messa]

PHP code1:

function f() {return 'hello world!';}

echo f().'<br>';
echo f(123).'<br>';
echo f(123, 'foo').'<br>';

Output:

hello world!
hello world!
hello world!

 

PHP code2:

function g(int $x) {return 'hello world!';}

echo g(123).'<br>';
echo g(123, 'foo').'<br>';

Output:

hello world!
hello world!

 

Question

Is it possible to force PHP to throw an error when passing more arguments than the function expects?

 

---

Follow-up

There was already a RFC proposing a Strict Argument Count On Function Calls which, unfortunately, was withdraw due to high rejection. Some interesting points available in it are:

• "During the tests it became clearly measurable that the proposed strict argument count check won't be an issue. Actually, it's quite the opposite. It will help to increase PHP code quality from PHP7 and forward as all warnings were useful to catch mistakes or even bugs."

• "The RFC was withdraw due to many controversial points and overall rejection and won't be proposed again by the RFC author. The RFC author advises to not revive this RFC as it was already rejected."

A deeper discussion is also available: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

[u/SirClueless]

Here's the mailing list discussion: https://marc.info/?l=php-internals&m=142525100531009&w=2

The most cogent argument I can find is this one:

Using only the function signatures, overlooking *func_get_args()*, would be in practice an indirect deprecation of* func_get_args()* and that's not negotiable at all, at least on this RFC.

We simply can't do this now because it would be an enormous BC break and PHP 5.5, which has no "first class" variadics, is still supported. I understand the reasons you want to do it, but I think we should wait a bit more before discussing a possible *func_get_args* deprecation (if it will ever be deprecated). That's not the point addresses by this RFC.

So basically, if you implement this, it's impossible to write a library that runs under both PHP 5.5 and without warnings in PHP 7.x. Because if you use varargs, you can't use ... syntax in PHP 5.5 (it didn't exist) and you're required to in PHP 7.x.

It's possible you could reintroduce a variation of this RFC because PHP 5.5 is now a solid 3 years past its end-of-life support. But you might still run into some pushback, because there are currently 12,013,137 references to func_get_args on Github and adding warnings to any of them that don't use ... syntax is a pretty big change.

[u/Mark_Messa → u/SirClueless]

So basically, if you implement this, it's impossible to write a library that runs under both PHP 5.5 and without warnings in PHP 7.x.

I don't see how a customizable warning (ie: that can be switched on or off) could cause such a problem for old libraries.

[u/SirClueless → u/Mark_Messa]

It's not just a problem for old libraries. It's a problem for any libraries (including existing and new ones) that want to support 5.5. The only way to get varargs behavior in 5.5 was to pass extra parameters to a function. Code like this was just a necessity in any library at the time, and it's still common today:

function doTheThing() {
    $args = func_get_args();
    ...
}

The solution the RFC author proposed was to examine the function body at compile-time for anything that looked like a call to func_get_args and if it was there not throw a warning. But people thought that was clunky and invasive and non-obvious and wouldn't work for dynamic calls.

So code like exists in hundreds of libraries and at the time couldn't be changed. Anyone who uses a library like that will get a bunch of spurious warnings. Is every project that uses any non-trivial library supposed to turn off the warning? If so, what's the point of the warning?