Re: [RFC] Deprecate implicitly nullable parameter type

From: Date: Tue, 23 Jan 2024 13:02:03 +0000
Subject: Re: [RFC] Deprecate implicitly nullable parameter type
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-122232@lists.php.net to get a copy of this message
On Tuesday, 23 January 2024 at 02:45, Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl> 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

« previous php.internals (#122232) next »