[php-src] Issue #12956: Spread against named parameters too strict
| From: | mindplay-dk | 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_