[RFC] Replace "Missing argument" warning with "Too few arguments" exception View as Markdown

hi,
Please take a look into the proposal.

https://wiki.php.net/rfc/too_few_args

My first thought went into how people use func_get_args() as this is (in
a sense) the opposite thereof.

That said I couldn't think of a good reason to disagree, but maybe
someone has a valid example where this change would have unforeseen
consequences.

~Florian

hi,

Please take a look into the proposal.

https://wiki.php.net/rfc/too_few_args

The RFC is extremely simple (both proposal and implementation) and almost completely described by the email subject.

I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm going to start the vote on next week.

I like the concept behind this, but I worry it might have a rather large
BC impact. Like removing call-time pass-by-reference, there may be a lot
of long-untouched code that needs fixing to work within this constraint.
I'm not even sure how easy it would be for static analysis to identify
these cases. I guess on the flip-side, people will probably have
Warnings displayed or logged already...

The RFC would also benefit from more discussion of the current behaviour
in different cases:

function foo($a) {}
foo(); // Warning

function bar(A $a) {}
bar(); // Error

function baz(A $a=null) {}
baz(); // OK

function quux(?A $a) {}
quux(); // Not sure. Error?

function wibble(int $a) {}
wibble(); // Error (regardless of strict_types, I think)

function wobble(?int $a) {}
wobble(); // Error?

Any other cases?

Certainly, making these consistent would be nice, but like a lot of
consistency, does it come at too high a price?

Regards,

Rowan Collins
[IMSoP]

Evening,

Could you expand on the "obvious optimization opportunities" in the

document ?

They are not obvious to me, and even if they were, this document is

part of the history of this change, so a little more detail would be nice.

Cheers
Joe

hi,

Please take a look into the proposal.

https://wiki.php.net/rfc/too_few_args

The RFC is extremely simple (both proposal and implementation) and almost
completely described by the email subject.

I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm
going to start the vote on next week.

Thanks. Dmitry.

hi,

Please take a look into the proposal.

https://wiki.php.net/rfc/too_few_args

The RFC is extremely simple (both proposal and implementation) and almost completely described by the email subject.

I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm going to start the vote on next week.

Thanks. Dmitry.

+1 on this change. IMO, this is one of the few remaining unusual PHP behaviors that exists for no obvious reason. A function should not be called if too few arguments are provided.

While this might be considered a BC break, I can't imagine there's an actual code out there relying on suppressing the warning just to call a function without enough arguments. I see no problem putting this change in 7.1.

Aaron Piotrowski

Hi!

Please take a look into the proposal.

https://wiki.php.net/rfc/too_few_args

The RFC is extremely simple (both proposal and implementation) and almost completely described by the email subject.

Looks fine to me. I don't think having undef function parameters is a
very valuable feature that is widely used.

--
Stas Malyshev
smalyshev@gmail.com

hi,

Please take a look into the proposal.

https://wiki.php.net/rfc/too_few_args

The RFC is extremely simple (both proposal and implementation) and almost
completely described by the email subject.

I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm
going to start the vote on next week.

Quick question, I think the error message might be a little confusing
asking for "exactly $n" parameters, because it could be a variadic function
using func_get_args(), shouldn't the message be?

throw Error("Too few arguments to function %s(), 0 passed in %s on line %d
and at least %d expected")

This only changes the case where the passed arguments are smaller than the
required ones or not? This is acceptable BC, but passing more arguments
should still not be an error.

Thanks. Dmitry.

Am 01.06.2016 um 12:55 schrieb Dmitry Stogov dmitry@zend.com:

hi,

Please take a look into the proposal.

https://wiki.php.net/rfc/too_few_args

The RFC is extremely simple (both proposal and implementation) and almost completely described by the email subject.

I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm going to start the vote on next week.

Thanks. Dmitry.

Very nice!

Just a question: Does the RFC also impact calls to internal functions? (With internal functions we don't have the problem as they're typically immediately aborted, but it would be inconsistent with userland functions to have once a warning, once an exception)

Judging from the patch this isn't the case? (at least I see no related changes)

Thus I think the scope of the RFC is a bit too small. [and at least it should be explicitly mentioned in the RFC if you decide against that].

Bob

In the SSA optimisation framework (part of opcache), we predict and
propagate types of variables.

We also may detect situations when some variables may be undefined.

If variable can't be "undefined", we may avoid unnecessary run-time checks
(e.g .like in ZEND_ADD_LONG handler).

Local variables almost always initialized before usage, but with exiting
behavior, function arguments always may be uninitialized.

To expand on this a bit... if a variable is potentially undefined, we
pretty much have to exclude it from optimization entirely, as nearly any
transformation we can make is prone to impact the undefined variable notice
in some way (remove, duplicate, reorder). The saving grace here is that
(untyped) function parameters don't have any type information, so we
typically can't apply transformations anyway (e.g. type specialization is
obviously not applicable, but many other transformation require guaranteed
warning/notice freedom, which usually requires more specific type
information than "any").

However, there are some optimizations that would be applicable if not for
the fact that the variable is potentially undefined. One such example is
copy propagation. Namely, in

function test($param) {
$var = $param;
// ...
use($var);
}

we wouldn't be able to simply replace all uses of $var with $param and save
that assignment, because this might duplicate or reorder "undefined
variable" notices. Such "useless" variable-to-variable assignments are
typically introduced by inlining. (Note: Both copy propagation and inlining
are not currently in php-src, but may well be in the future.)

Nikita