Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117525
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>
In-Reply-To: <CAFPFaMLx3pA7SS2aefcgG88ucqZAUK_F=eRpMn=3XL1_JVCsxw@mail.gmail.com>
Date: Wed, 13 Apr 2022 20:43:00 +0100
Message-ID: <CAFv4g+HgaKifuCNXGc9yqib5py2oLNM-FzmGT0Jjs-baa=hq8g@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000045611405dc8e69ad"
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

--00000000000045611405dc8e69ad
Content-Type: text/plain; charset="UTF-8"

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 with
> strict_types so that the possibility of dropping strict_types all together
> wouldn't be outrageous.
> I've written about this elsewhere and on this list already but main points
> 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 that
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 paragraph
> 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 in
a `strict_types=1` 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 NULL
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 the
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 exception.
>


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 want
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 this
> 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 the
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 accept
> 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, and
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 would
be happy with.

Craig

--00000000000045611405dc8e69ad--