[PHP 8.4] Fixes for implicit nullability deprecation

[Ayesh]

Fixes all issues that emits a deprecation notice on PHP 8.4.

See:

• RFC
• PHP 8.4: Implicitly nullable parameter declarations deprecated

[shadowhand]

Note: This syntax is supported as of PHP 7.1.0, and predates generalized union types support.

As this package supports PHP 7.0, we cannot use nullable types without other changes.

Additionally, such changes MUST be targeted to the PHP-FIG specification before being targeted to the implementation. cc @mbniebergall @Jean85 @weierophinney

[Ayesh]

Thanks for the quick review. You are right, we can't make these changes without bumping the minimum PHP version to 7.1+.

As far as specification goes, I think this is merely an implementation detail. Both string $clientFilename = null and ?string $clientFilename = null are effectively identical for LSP and Reflection APIs, so changing this should have no impact on PSR implementations.

[weierophinney]

@shadowhand int $paramName = null is semantically equivalent to ?int $paramName, and it's been that way since parameter type hints were introduced; PHP just didn't formalize the concept of nullable types until 7.1.

I think at this point, it's fine to bump to 7.1. When you look at Packagist stats, across all packages, 7.0 only has a 1.3% usage... and when you look at the http-factory stats... it has 0% usage. I think we can safely bump.

[weierophinney]

Per my note, I think it's safe to do this, but we also need to bump the minimum supported PHP version to 7.1 as part of this request, and it should target a new minor.

I also don't think we need to change the spec, as the change doesn't introduce any change in behavior, nor, when we target 7.1, does it change the signature in any way that is backwards incompatible.

[Jean85]

I agree with @MWOP considerations, and our evolution bylaw does exactly these considerations and requirements. The same bylaw, though, requires the equivalent of an errata vote (and a spec+meta adaptation) to approve this new minor version; I suggest that we proceed with that, even if we can expect an easy, unanimous approval.

[nicolas-grekas]

@Ayesh let's change the branch-alias in composer.json and bump to PHP >= 7.1
What's the status of this PR, FIG-wise? This is making the Symfony CI fail on PHP 8.4 so it'd be great fixing ASAP.

[Jean85]

What's the status of this PR, FIG-wise?

We need to follow the PSR evolution bylaw, which means:

• fixing this PR:
  • bumping to PHP 7.1+ is required (to make it work correctly without BCs)
  • it's also allowed, since we did the same i.e. with PSR-7 from 1.0 to 1.1
• we need also a PR on the PSR meta document to note the changes, as required in the bylaw
• when that's ready, the editor @shadowhand can call for a vote to approve the two PRs
• when that's done, we can merge both PRs, tag & release

[shadowhand]

Superseded by #17