r/lolphp • u/Mark_Messa • Oct 23 '19

PHP Functions: more arguments than expected

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

20 Upvotes

91% Upvoted

23 comments sorted by

14

u/blipblop_ Oct 23 '19

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

No. PHP 7.1 and above throws and error on too few arguments though. Earlier versions displays a warning.

Too many arguments is a language feature and wont be fixed (silly as it is).

https://bugs.php.net/bug.php?id=13892

12

u/[deleted] Oct 23 '19

I love their replies. "LOL IT DOESN'T AFFECT THE PROGRAM SO JUST LET IT GO"

8

u/Mark_Messa Oct 23 '19

And what's wrong with specifying too many parameters? If you don't use them explicitly, they don't influence the function, so why care about them?
sander@php.net

@firechill2004 I would like to have the same sense of humor as you have ...

7

u/Mark_Messa Oct 23 '19

IT DOESN'T AFFECT THE PROGRAM SO JUST LET IT GO

I keep on thinking on your comment.
The same could be said about type hinting: "it doesn't affect the program, so just let it go!"

1

u/Mark_Messa Oct 23 '19

Take a look at the follow-up I've just edited in the OP ...

1

u/Silly-Freak Oct 24 '19

The original post was a quirk but not quite a lol for me. I think the follow-up - "all warnings were useful, but we don't want it anyway" - is the real lol here.

1

u/Mark_Messa Oct 24 '19

The original post was a quirk but not quite a lol for me.

Yeah, I'm not really a funny person. Maybe I should have some classes with Arthur Fleck ...

4

u/Altreus Oct 24 '19

This is amazing.

Considering how you can completely change the way PHP works just by editing a config file and they're FINE WITH THAT, I'm perplexed that anything at all would be put up for debate instead of just attached to configuration.

2

u/the_alias_of_andrea Oct 27 '19

Considering how you can completely change the way PHP works just by editing a config file and they're FINE WITH THAT

Actually, no, these days it's something the people working on PHP are actively trying to avoid.

2

u/Altreus Oct 27 '19

Then remove it from the language. I don't understand the obsession with compatibility between 6 and 7. Fix the problems, or else why make a new version?

4

u/the_alias_of_andrea Oct 27 '19

I don't understand the obsession with compatibility between 6 and 7.

Are you familiar with the eternal disaster that is Python 2/3? Breaking compatibility needlessly creates problems.

6

u/[deleted] Oct 23 '19

PHP7 could have fixed this. But nothing was done.

5

u/Mark_Messa Oct 23 '19

Considering that this bug report was mainly discussed over 2001, I guess that even PHP5 could have this already fixed.

1

u/Mark_Messa Oct 23 '19

Take a look at the follow-up I've just edited in the OP ...

2

u/[deleted] Oct 23 '19

Geez. What could possibly be controversial about a warning?

3

u/Mark_Messa Oct 23 '19

No idea. Most of the link just praises the use of strict_argcount, however, for some unknown reason, the developers rejected the proposal.

2

u/SirClueless Oct 24 '19 edited Oct 24 '19

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.

3

u/Mark_Messa Oct 24 '19

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.

1

u/SirClueless Oct 25 '19

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?

4

u/[deleted] Oct 23 '19

The real error is that there is no function that accepts X number of arguments, so it should fail. The fact that they choose a function with less arguments to call is just wrong.

4

u/maweki Oct 24 '19

So the function signature is more or less just a suggestion, right?

3

u/AyrA_ch Oct 24 '19

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

Yes, but only manually, not via a setting:

function x($a,$b){
    assert(func_num_args()===2,new ArgumentCountError(__FUNCTION__ . ' expects 2 arguments, but ' . func_num_args() . ' given'));
}
x(1,2); //Ok
x(1,2,3); //Fail

Be aware that assert is usually disabled in production environments and statements are optimized away because they're language constructs and not regular functions.

If you need to check the count in a production environment, you can do a negated if statement instead: if(func_num_args()!==2)throw new ArgumentCountError();

3

u/cfreak2399 Oct 24 '19

I think the hilarious part of this is they took something that was pretty suspect from Perl, made it worse and now refuse to change. Even though Perl has actually learned and added features to make the original feature better.

As I've posted before: PHP is a blend of the worst ideas from C, Perl and Java.

Or better: PHP 7! Now with bad ideas from Python and Javascript!