null default-value parameter before required parameter is silently ignored

[syranide]

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]

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]

@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]

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