Skip to content

null default-value parameter before required parameter is silently ignored #11485

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
syranide opened this issue Jun 19, 2023 · 3 comments
Closed

Comments

@syranide
Copy link

syranide commented Jun 19, 2023

Description

The following code:

<?php
function foobar(
    string|null $a = null,
    string $b
) {}

foobar(b: "x");

Resulted in this output:

Fatal error: Uncaught ArgumentCountError: foobar(): Argument #1 ($a) not passed

But I expected this error instead:

Deprecated: Optional parameter $a declared before required parameter $b is implicitly treated as a required parameter

To explain; $a does not end up being optional, and if you perform reflection on the property, it does not have a default-value. So PHP is silently ignoring the user-specified behavior. While it seems that PHP considers having optional properties in-front of required properties as invalid, it should at least issue a warning instead of silently changing expectations. If you put a string as default-value instead, it will emit the above depreciation notice.

PHP Version

PHP 8.2.7

Operating System

No response

@KapitanOczywisty
Copy link

Note that a default value of null can be used before required parameters to specify a nullable type, but the parameter will still be required.
https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.core.optional-before-required

This was old way to make nullable types, which was kept for compatibility, though I don't think it should be supported anymore.

Originally PR #5067 included also this case, but it was changed as per this message.

@syranide
Copy link
Author

@KapitanOczywisty Thank you, very informative. I see how there's a bit of quirkiness due the desire to support "poor mans nullable type" for now then. Although it seems like this specific case was already discussed and only skipped because "it didn't seem worth it".

function f3(?A $a = null, $b) {}

"f3 could technically emit one, but I'm not sure it's worth having a special case of a special case for this."

So yeah, there could be a deprecation for it, and I would argue there should be, but maybe it's too niche until "poor mans nullable type" is entirely deprecated.

However, after reading more on that topic and further testing it appears I reduced the example too far. Our use-case is constructors with the promoted property syntax, which behaves differently it seems, and there it specifically seems like a bug due to the behavior of the other cases. I'll open a new issue instead to correctly detail the problem.

@iluuu1994
Copy link
Member

This is really the same as #11488, see https://3v4l.org/G1oVv. #11497 should take care of this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants