No deprecation warning is triggered for nullable optional parameters before required ones

[m-vo]

Description

The following code:

<?php

function foo(int $param_optional = null, int $param_required) {}

Resulted in this output:

(no deprecation warning triggered)

But I expected this output instead:

Deprecated: Optional parameter $param_optional declared before required parameter $param_required is implicitly treated as a required parameter in […]```

It seems having a nullable parameter will prevent the deprecation from being triggered. See https://3v4l.org/biVG1#v8.1.2 for a comparison.

PHP Version

>=PHP8.0

Operating System

No response

[iluuu1994]

This is by-design.

https://github.com/nikic/php-src/blob/b63436ab67e1644d3611fba91c89c45a7a845626/Zend/zend_compile.c#L5753-L5759

The impact of this change was small, because it was restricted to explicitly-nullable parameters. Adding it to all parameters would probably require an RFC.

Fulll context: #5067

[iluuu1994]

@m-vo Realted to #3535. The was recently closed because there wasn't any response from the author.

Are you ready to go through the RFC process yourself?

[m-vo]

@iluuu1994 Thanks for the detailed background information! I wasn't aware that there is actually a difference between ?Type $foo = null and Type $foo = null, I always thought they are synonyms.

@nikic pointed the following out in #5067 (comment):

function test($param = null, $param2) is strictly equivalent to function test($param, $param2). You can just drop the useless and confusing = null, there are no BC implications whatsoever for that case.

This makes sense to me, but maybe then there is a point in deprecating this behavior altogether (the "confusing = null"), because it's likely a bug now. I fear I'm not deep enough in the PHP internals to judge about implications or to go through a RFC process, though.

[iluuu1994]

@m-vo I agree that the behavior doesn't make sense anymore. Although it causes minimal harm in terms of maintenance of php-src or userland code and is probably easily caught by a linter. Anyway, many internals are against breaking changes that don't have a clear benefit, so I think an RFC is required here.

Creating an RFC isn't hard. https://wiki.php.net/rfc/howto

The most time-consuming part is probably the mailing list. Maybe you could send an initial e-mail, see what the response is like and decide if you want to pursue this. If not, this issue will likely be closed.