Re: [RFC] Deprecate implicitly nullable parameter type
On Tuesday, 23 January 2024 at 02:45, Juliette Reinders Folmer
<[email protected]> wrote:
> On 23-1-2024 3:18, Gina P. Banyard wrote:
> > > The RFC notes that PHPStan and friends have an easy flag to make the change, which is
> > > great, but still that's a minority of PHP devs that even know to use static analysis.
> > > One does not need to use a static analyser to determine or fix this issue, indeed, I
> > > didn't even mention static analysers in the RFC as PHP_CS_FIXER is a tool for enforcing coding
> > > styles and is capable of fixing this issue.
> > > This tool and other code formatting tools are used more widely and for longer than
> > > static analysers.
>
> While I concur that too few devs use the helpful tooling available to
> them, I can already tell you that PHPCompatibility for PHP_CodeSniffer
> will be able to detect and flag code subject to this deprecation without
> problems and I will make sure the sniff is available ahead of the PHP
> 8.4 release (providing the RFC passes).
>
> And the Slevomat Coding Standard for PHP_CodeSniffer already contains
> the SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue
> sniff to auto-fix non-nullable typed parameters with a null default
> value to be nullable typed as well, so it's not just CS-Fixer which can
> help with this.
I had a hunch that PHP_CodeSniffer was able to handle this already, I just couldn't find the
correct sniff. :)
I'll mention it if/when I update the RFC text.
Best regards,
Gina P. Banyard
Thread (23 messages)