Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122230
Date: Tue, 23 Jan 2024 02:18:19 +0000
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Message-ID: <pqNqnDTBZCeis6FA4j7mCDkENEfIpkN1-mUFziGcazrqbmp6GDQkFdlmOZVl0pUBdf_BJMCSPXz6Tqt19MCkUorZeXDCuC6fuAPBbxU4LzQ=@gpb.moe>
In-Reply-To: <344c3e06-3822-4b20-9a6f-a58fb64929a7@app.fastmail.com>
References: <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe> <344c3e06-3822-4b20-9a6f-a58fb64929a7@app.fastmail.com>
Feedback-ID: 96993444:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
From: internals@gpb.moe ("Gina P. Banyard")

On Monday, 22 January 2024 at 18:53, Larry Garfield <larry@garfieldtech.com=
> wrote:
> I am in support of this change. My only concern is timeline. This RFC wou=
ld deprecate it in 8.4, and presumably support would be removed in 9.0. Whi=
le we haven't discussed a timeline for 9.0, historically the pattern is eve=
ry 5 years, which would put 9.0 after 8.4, which means only one year of dep=
recation notices for this change.

There is no reason as to why 9.0 should come after 8.4, and I fundamentally=
 disagree with the logic that we somehow need to "plan" deprecations around=
 how much time we need to provide users to upgrade.
To this day, I have never been provided any evidence that longer deprecatio=
n times actually lead to users upgrading their code sooner and not delay th=
e inevitable.
We were even told to shunt mass deprecation RFCs for 8.0 to 8.1, effectivel=
y reducing how much time users have to upgrade for the sake of simplifying =
the migration from 7.4 to 8.0.

The idea for this RFC was floated around the time of PHP ***7***.4, but thi=
s was deemed too soon due to cross version compatibility.

Moreover, asking core developers to magically figure out all the various wa=
ys PHP is bonkers or broken in a specific narrow time frame, just so userla=
nd can have X version where the deprecation exists until removal, is unreas=
onable.
If this is the model that we should seek, then we should *completely* move =
away from our current versioning system and do something more like Python t=
hat provides 2 version where a feature is deprecated before removing suppor=
t.
E.g. features deprecated in Python 3.9 were removed in Python 3.11.

As such, I will not entertain this idea of timelines and when it is the "ri=
ght time" to deprecate something for it to be removed at the "right time".

If this is something people feel strongly, an RFC to change what our versio=
ning is and means should be done instead.

> 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 c=
lean up and it would be another "OMG you broke everything you evil Internal=
s <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 iss=
ue but well-written code is seemingly the minority.)

I find this comparison disingenuous, fixing undefined variables is one, if =
not two orders of magnitude harder than fixing this issue.
Fixing implicit null to scalar types coercions for internal functions cause=
s way more havoc than this for legacy codebases, and yet we have consistent=
ly maintained the rationale for the deprecation.

While I do take into consideration the impact RFCs can have on existing cod=
e bases, I consider having clear, easy, and comprehensible semantics to be =
way more important than supporting some complicated and confusing semantics=
 for the sake of BC.
There will always be code running on a completely outdated version of PHP d=
ue to whatever reason.
And refusing to fix the language and its semantics for the vast majority of=
 new code that is going to be written in it feels like a bad decision to me=
.
Especially if fixing it results in engine simplifications.

We are our own project, and we need to make choices for the sake of the hea=
lth of the project, and this means removing stuff in a reasonable timeline.
I personally don't work on PHP to do legacy maintenance and keep running it=
 at all cost, if I did want to do this I'd be writing COBOL.
I work on PHP because I believe it has a long future ahead of itself, and t=
hat new people will learn it and use it.
And forcing those people to need to learn, and remember bazillions of gotch=
as really doesn't sound fair to them IMHO.

> The RFC notes that PHPStan and friends have an easy flag to make the chan=
ge, 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 i=
s 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 long=
er than static analysers.


Best regards,

Gina P. Banyard