Re: RFC idea: using the void type to control maximum arity of user-defined functions

From: Date: Fri, 05 Apr 2024 10:24:30 +0000
Subject: Re: RFC idea: using the void type to control maximum arity of user-defined functions
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-122962@lists.php.net to get a copy of this message
Hi On 4/4/24 23:27, Ilija Tovilo wrote:
I think it would be reasonable to consider deprecating passing extra arguments to a non-variadic function.
IIRC one of the bigger downsides of this change are closure calls that may provide arguments that the callee does not care about. […] The user may currently choose to omit the $key parameter of the closure, as it is never used. In the future, this would throw. We may decide to create an exemption for such calls, but I'm not sure replacing one inconsistency with another is a good choice.
I must admit, I find the
This RFC considers that anonymous functions are not intended to have a formal signature and should skip the exceeding argument count check.
bit of the previous RFC pretty reasonable to reduce the impact of the deprecation: I expect this type of callback to primarily be implemented as a single-use closure, which aren't really part of a package's API and thus relaxed checks are fine for those. I also don't primarily see deprecating passing of superfluous parameters as removing an inconsistency. The more important bit for me is the improved error checking, i.e. I'd prefer to resolve the inconsistency in favor of the stricter checks, instead of relaxing the checks for internal functions. The previous RFC showcases multiple examples where it found bugs that likely were introduced during refactoring. Best regards Tim Düsterhus

« previous php.internals (#122962) next »