On Wed, Apr 13, 2022 at 9:45 PM Craig Francis <cr...@craigfrancis.co.uk> wrote: > > https://wiki.php.net/rfc/null_coercion_consistency > > On Wed, 13 Apr 2022 at 15:15, G. P. B. <george.bany...@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
I don't have a vote, so my opinion only goes so far. But here's my 2ยข. > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
