Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117526
MIME-Version: 1.0
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com>
 <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
 <CAFPFaMLx3pA7SS2aefcgG88ucqZAUK_F=eRpMn=3XL1_JVCsxw@mail.gmail.com> <CAFv4g+HgaKifuCNXGc9yqib5py2oLNM-FzmGT0Jjs-baa=hq8g@mail.gmail.com>
In-Reply-To: <CAFv4g+HgaKifuCNXGc9yqib5py2oLNM-FzmGT0Jjs-baa=hq8g@mail.gmail.com>
Date: Thu, 14 Apr 2022 09:31:34 +0200
Message-ID: <CAPzBOBPtUZv4ZoMkTxptkhigWnGRBOyj7zq+iGFONABS3N_UEA@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: "G. P. B." <george.banyard@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: landers.robert@gmail.com (Robert Landers)

On Wed, Apr 13, 2022 at 9:45 PM Craig Francis <craig@craigfrancis.co.uk> wr=
ote:
>
> https://wiki.php.net/rfc/null_coercion_consistency
>
> On Wed, 13 Apr 2022 at 15:15, G. P. B. <george.banyard@gmail.com> wrote:
>
> > I've spent a large amount of time making coercive typing mode more
> > sensible and aligning the behaviour as close to reasonably possible wit=
h
> > strict_types so that the possibility of dropping strict_types all toget=
her
> > wouldn't be outrageous.
> > I've written about this elsewhere and on this list already but main poi=
nts
> > are located here: https://github.com/Girgias/unify-typing-modes-rfc
> >
>
>
> Thank you George, I do appreciate your work on this, I agree with pretty
> much everything you have written, and I really do want PHP to move in tha=
t
> direction.
>
> The *only* thing I disagree with is NULL coercion, because it has worked
> perfectly well for years, and is used so often.
>
>
>
> Userland scalar types, however they would have been introduced, did not
> > include coercion from NULL for *very* good reasons.
> > Wanting to change this behaviour needs more justification than a paragr=
aph
> > in docs, as the docs should reflect the reality of the implementation.
> >
>
>
> Some people see NULL as an invalid value, which can sometimes be useful i=
n
> a `strict_types=3D1` environment, but that's the only "good reason" I can
> find... it's why I changed my mind about making some parameters nullable,
> and took a different approach with this RFC.
>
> But most developers do not use NULL like that, and that's why it's passed
> so often to the ~335 function parameters I've noted (most of them are on
> the list because they realistically receive user values, which can be NUL=
L
> in most frameworks).
>
>
>
> The second aspect is the general consensus that internals and userland
> > should behave identically.
> >
>
>
> Yep, they really should... it's why I said we "Must keep the spirit of th=
e
> original RFC, and keep user-defined and internal functions consistent".
>
>
>
> Moreover, the fact that we are deprecating this and not just changing the
> > behaviour from one version to another is that we do recognize PHP
> > developers use NULL in this way, and we are giving them advance notice =
of
> > the change.
> > Also a deprecation notice should, IMHO, never be promoted to an excepti=
on.
> >
>
>
> Unfortunately deprecation notices are being ignored (as noted in my RFC,
> with examples on how); and there is the intention to use Type Error
> Exceptions in 9.0 (the thing I'm trying to avoid).
>
> I'm approaching this from a security point of view - the last thing I wan=
t
> to do in ~5 years is auditing code/systems where they have stuck with 8.x
> because it's too hard to upgrade.
>
>
>
> There are behaviours of PHP that will probably never be "fixable", but th=
is
> > should not prevent us from improving the aspects we can.
> > And if we only focused on how developers use PHP we would still have
> > register globals, magic quotes, etc.
> >
>
>
> I want the language to be better as well, and I was *very* glad to see th=
e
> back of Register Globals and Magic Quotes (I know they were a pain to
> remove, but it was well justified, as they caused so many problems).
>
>
>
> Clearly it seems you won't listen to why these changes were made and want
> > to reverse course, therefore good luck convincing enough people to acce=
pt
> > such an RFC.
> >
>
>
> I have been listening/reading (it's why I've taken about 2 hours to read
> what you have written, and reply). I have also been discussing this with
> different people (on and off list)... unlike the original RFC discussion,
> where it was only Craig Duncan that mentioned this issue:
>
> https://externals.io/message/112327#112531
>
> And it's because I've been listening to people that I changed my mind, an=
d
> created this new RFC (as noted above).
>
>
>
> I think I've said all there is to say and won't interact further with any
> > such proposals.
> >
>
>
> That's a shame, as I'd like to discuss solutions to this problem you woul=
d
> be happy with.
>
> Craig

I don't have a vote, so my opinion only goes so far. But here's my 2=C2=A2.

> I see null as a real type

This confuses me. I see "false" and "true" becoming their own types,
so what is a boolean? The language currently has no way to express
aliases of types, otherwise I'd say a boolean is an alias "true|false"
but it doesn't. What happens if a function returns the "false" type
and I pass it to a function that only allows "bool"? I expect it to
work. So naturally, there is some coercion in there as well, and it
would be great if null got the same treatment where old codebases
benefit without taking away the advantage for newer codebases.

I see this RFC as a balance in that regard, because real life is
messy. I really hope it passes and good luck!

Robert Landers
Software Engineer
Utrecht NL