Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122224
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-119-ga8b98d1bd8-fm-20240108.001-ga8b98d1b
MIME-Version: 1.0
Message-ID: <344c3e06-3822-4b20-9a6f-a58fb64929a7@app.fastmail.com>
In-Reply-To: 
 <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe>
References: 
 <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe>
Date: Mon, 22 Jan 2024 18:53:42 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jan 22, 2024, at 9:50 AM, Gina P. Banyard wrote:
> Hello internals,
>
> M=C3=A1t=C3=A9 Kocsis and myself would like to propose deprecating imp=
licitly=20
> 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 patt=
ern is every 5 years, which would put 9.0 after 8.4, which means only on=
e 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 I=
nternals <expletive deleted>!" like the "undefined is now warning" chang=
es in 8.0.  (In both cases, well-written code any time from the past dec=
ade 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 cha=
nge, which is great, but still that's a minority of PHP devs that even k=
now to use static analysis.

The only solution I can think of is to keep the deprecation in place unt=
il PHP 10, but that's a very long time from now and the RFC says this si=
mplifies 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 transitio=
n more graceful.

Again, fully support the change, I just want to make sure it's graceful.

--Larry Garfield