Re: [RFC] Deprecate implicitly nullable parameter type

From: Date: Mon, 22 Jan 2024 18:53:42 +0000
Subject: Re: [RFC] Deprecate implicitly nullable parameter type
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Mon, Jan 22, 2024, at 9:50 AM, Gina P. Banyard wrote:
> Hello internals,
>
> Máté Kocsis and myself would like to propose deprecating implicitly 
> nullable parameter types.
>
> The RFC is available on the wiki at the following address:
> https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
>
>
> Best regards,
>
> Gina P. Banyard

I am in support of this change.  My only concern is timeline.  This RFC would deprecate it in 8.4,
and presumably support would be removed in 9.0.  While we haven't discussed a timeline for 9.0,
historically the pattern is every 5 years, which would put 9.0 after 8.4, which means only one year
of deprecation notices for this change.

Given the massive amount of code that built up between 5.1 and 7.1, and 7.1 and today, I worry that
a year won't be enough time for legacy code to clean up and it would be another "OMG you
broke everything you evil Internals <expletive deleted>!" like the "undefined is now
warning" changes in 8.0.  (In both cases, well-written code any time from the past decade has
no issue but well-written code is seemingly the minority.)

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.

The only solution I can think of is to keep the deprecation in place until PHP 10, but that's a
very long time from now and the RFC says this simplifies a decent amount of engine code, so I'm
not wild about that idea..  I am open to alternate suggestions for how we can make this transition
more graceful.

Again, fully support the change, I just want to make sure it's graceful.

--Larry Garfield


Thread (23 messages)

« previous php.internals (#122224) next »