[php-src] Issue #12956: Spread against named parameters too strict

From: Date: Fri, 15 Dec 2023 12:22:27 +0000
Subject: [php-src] Issue #12956: Spread against named parameters too strict
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-246050@lists.php.net to get a copy of this message
Issue: https://github.com/php/php-src/issues/12956 Author: mindplay-dk ### Description The following code: ```php <?php function test( int $id, string $name ) { return [$id, $name]; } print_r(test(...["id" => 123, "name" => "Rasmus"])); print_r(test(...["id" => 123, "name" => "Rasmus", "lol" => "nope"])); // Fatal error: Uncaught Error: Unknown named parameter $lol ``` Resulted in this output: ``` Array ( [0] => 123 [1] => Rasmus ) Fatal error: Uncaught Error: Unknown named parameter $lol in /in/nLRfD:12 Stack trace: #0 {main} thrown in /in/nLRfD on line 12 Process exited with code 255. ``` But I expected this output instead: ``` Array ( [0] => 123 [1] => Rasmus ) Array ( [0] => 123 [1] => Rasmus ) ``` [run on 3v4l.org](https://3v4l.org/nLRfD#v8.3.0) I'm not usually the one asking for *less* strictness, but throwing a **fatal** error for something that would otherwise succeed without problems, seems overly restrictive and unnecessary - there's no reason to crash the entire program because, let's say, some piece of client code starts posting an unused property. If we agree [what warning and notice generally means](https://stackoverflow.com/a/4624505/283851), I would suggest we make this a **notice**, or at least only a **warning**: > A notice is an advisory message meaning "You probably shouldn't be doing what > you're doing, but I'll let you do it anyway" > > A warning is a message saying "You are doing something wrong and it is very likely to > cause errors in the future, so please fix it." This definitely seems like a situation where you're "doing something you shouldn't be doing" - but throwing away an unused extra parameters isn't really "likely to cause errors", assuming there were enough parameters to satisfy the requirements. I suppose you could argue it's "likely to cause errors" if the issue is a simple typo - but in that case, you would almost definitely hit a missing argument error. The more likely situation is you've removed an unused argument from an API, and some clients are still posting that - this could easily be a normal and expected situation while migrating an API change independently of migrating some clients, during removal of an unused parameter. It definitely does not seem like any reason to stop the world. Am I missing something here? 🤔 ### PHP Version PHP 8.3.0 ### Operating System _No response_

« previous php.bugs (#246050) next »