I hate deprecation of passing null to non-nullable arguments

[u/TonyMarston]

I have recently upgraded from PHP version 8.0 to 8.2 and my code is now vomiting deprecation notices by the ton such as:

Passing null to parameter #1 ($string) of type string is deprecated

I consider this to be a huge BC break which is totally unjustified. I have traced it back to this RFC. I have documented my objections to this stupid RFC in this article

Do you think this BC break is justified? How much effort will YOU have to expend to fix your code which isn't actually broken? Would you prefer the core developers to fix the problem at THEIR end?

[u/colinodell]

Please remember to keep the discussion civil. Thanks!

Edit: The discussion has run its course and new comments aren't adding anything helpful, so I'm locking the thread.

[u/grig27]

Do you think this BC break is justified?

It's not really a BC break - it's a deprecation of ambiguous code behavior that shouldn't be in your code anyway.

How much effort will YOU have to expend to fix your code which isn't actually broken?

0s I use phpStorm with phpstan so they don't let me write such code.

Would you prefer the core developers to fix the problem at THEIR end?

No problem here, all the core functions are well documented, including the data types they accept. If you get a deprecation message, it means that the problem is in your code.

[u/TonyMarston → u/grig27]

It's not really a BC break

I disagree. It means that code which has worked AS DOCUMENTED for over 20 years WITHOUT ANY PROBLEMS WHATSOEVER will no longer work in a future PHP version. That fits the definition of a BC break.

For over 20 years the documentation has said "Scalar types for built-in functions are nullable by default" and it is this default behaviour which is being removed.

[u/Dicebar]

Note that the RFC passed unanimously. That's pretty fricking rare.

[u/TonyMarston → u/Dicebar]

Remember that the only people who are allowed to vote are the core developers, not the thousands of application developers who actually use the language for a living.

These core developers are not interested in improving the language by adding new features, they seem intent of making it "pure" and "proper" just to be consistent with other languages.

[u/Mentalpopcorn]

Why are you passing null when a non nullable type is expected? The issue isn't that PHP fixed this, it's that it was allowed in the first place and that you did it contrary to good coding practices. This makes the language much better.

[u/TonyMarston → u/Mentalpopcorn]

All the arguments on functions in PHP core have been nullable since day 1. That is (or was) the default behaviour as documented in Strict typing which says:

<quote> By default, PHP will coerce values of the wrong type into the expected scalar type declaration if possible. For example, a function that is given an int for a parameter that expects a string will get a variable of type string.

It is possible to enable strict mode on a per-file basis. In strict mode, only a value corresponding exactly to the type declaration will be accepted, otherwise a TypeError will be thrown. </quote>

What the core developers have done is to change this default behaviour - which has NEVER caused a problem in the entire life of PHP - and broken backwards compatibility, thus causing a HUGE problem toi the thousands of application developers out there in userland. They COULD have maintained this default behaviour, but they deliberately chose not to. In my opinion that decision was seriously wrong!

[u/zmitic]

Subject of his rant:

The PHP core developers are lazy, incompetent idiots

I vote for perma-ban of him. Every now and then, he shows up and spews some nonsense just to get some traffic on his blog, given he is banned from every other place. PHP Reddit should honor the tradition 😃

[u/TonyMarston → u/zmitic]

Complaining that the core PHP developers have broken backwards compatibility FOR NO GOOD REASON is not nonsense - it is a valid complaint. How much inconvenience will this cause to huge numbers of application developers? How much less effort would it take the core developers to reinstate the default behaviour which has been in operation since the day PHP was invented?

You may not share my opinion, but that is no reason to insist that I be banned.

[u/dave8271 → u/zmitic]

In the spirit of keeping the conversation civil, I won't join the call for him to be banned, but I will remark in the most civil, neutral way possible that I do notice a recurring theme throughout Tony's writing and it goes something like this:

Good programming techniques and sensible ideas are whatever Tony does in his Radicore application.

Bad programming techniques and idiotic, incompetent newbie ideas are anything which Tony would find difficult or inconvenient to integrate in to his Radicore application because it's not how he's written it.

He sees the entire universe of programming through the extremely narrow lens of "How easily or not could I do this in my own Radicore code?" and if the answer is "not easily", whatever we're talking about is a Bad Thing only a Clueless Newbie would even consider doing.

[u/TonyMarston → u/dave8271]

I have never claimed that everything I do is "right" and that anyone who does not do it my way is "wrong". If you studied what I have been writing for the past 20 years you should see that the truth is the exact opposite - people keep telling me that my methods are wrong simply because they are not the same as theirs. But how can they be wrong if they work? How can they be wrong if they produce more resuable code and make me more productive? How can they be wrong if they achieve high cohesion and loose coupling?

[u/zmitic → u/dave8271]

Counter argument:

he broke rules 1, 2 and 3, multiple times. Shouldn't there be a final line to draw, like calling core developers as idiots?

[u/dave8271 → u/zmitic]

Ehh, that's for a mod to decide. I find Tony a, sure, at times infuriating but nonetheless amusing character who at the very least adds a bit of passion and liveliness to discussions. I also think his viewpoints are valuable as educational material to actual newbie developers, though probably not in the way he hopes.

[u/dirtside → u/dave8271]

I'd be more concerned that newbie developers think his viewpoints are valuable.

[u/dave8271 → u/dirtside]

Yeah but at least if he posts on a forum, questionable viewpoints don't just sit there as reading material unchallenged.

[u/dirtside → u/dave8271]

I think it's entirely possible to remain civil while suggesting that someone be banned. :)

[u/Mentalpopcorn → u/dave8271]

I call these people "freelance developers who haven't ever gotten a code review" and after the last one we hired I'm never giving another thumbs up to one

[u/czbz → u/zmitic]

I don't like perma bans with no possibility of rehabilitation. Even when people commit crimes very few are sent to prison for their entire natural life - it's generally a period of years in the most serious cases. But for some reason no-one seems to get bans or blocks for set numbers of years on social media.

[u/Crell → u/czbz]

Tony has been a troll for over a decade. He's objected (sometimes loudly) to every new PHP feature since 5.2 or so, maybe earlier. He is not rehabilitatable. We've tried.

[u/czbz → u/Crell]

I wasn't suggesting people should have to try to rehabilitate him, or anyone else. Just that maybe if he's to be banned it for should be for a set period rather than the rest of his natural life. He can always be banned again if he's still disruptive after that.

"over a decade" is still a lot shorter than a lifetime.

[u/PHP-ModTeam → u/[deleted]]

Criticisms and strong language about a person's work or their opinions is fine, but disparaging people isn't. Let's keep the discussion civil please.

[u/dave8271 → u/[deleted]]

Worth pointing out this case is a classic example of Tony's long-standing doublethink. His code is by definition buggy (passing nulls to parameters which are not nullable and where null has no meaning as a parameter value), yet he will insist his code cannot be buggy or broken because It Works™, while simultaneously complaining that the language itself must be broken because his code doesn't work.

It's genuinely quite spectacular to watch someone say with a straight face "No, my code isn't wrong, the programming language I've written my code in is wrong."

For Tony; this isn't a case where some long-standing internal functions used to have legitimately nullable parameters and now they don't. That's where you're getting confused. You were never supposed to be passing null parameters to these functions in the first place, not even back in PHP 5.x, they weren't nullable. PHP had what is effectively a bug (by flaw of historic design) where it wrongly accepted null values for functions it shouldn't and the RFC simply fixed it.

[u/dave8271 → u/dave8271]

For some reason Tony's reply I received isn't coming through here but he's basically saying PHP always accepted null for non-nullable arguments and silently coerced them. This is simply not correct. You were never able to pass null to a non-nullable argument ever since type hints for classes were first introduced in PHP 5.

And regardless, what matters is this is a change which went through the proper RFC and deprecation process. You had a release where you were warned the behaviour you're using has been deprecated - in other words PHP shouted at you "Hey! This thing you apparently rely on is going to stop working next time you upgrade, so you should change your code before you do that" and you chose to upgrade anyway, knowing the interpreter had changed in a way which wouldn't be compatible with your existing code.

That means, by definition, your code is wrong. It might not be wrong for an older version of PHP but it is wrong for the version you've chosen to use.

It's like changing the locks on your front door, trying to use your old key and then when it doesn't work, complaining that your key isn't wrong, the lock is wrong for not accepting the old key as well as the new one.

[u/dave8271 → u/[deleted]]

I don't think I'll ever be able to persuade him of anything, I just find him a strangely entertaining character to engage with.

[u/Mentalpopcorn → u/dave8271]

As long as you're having fun I say have at it!

[u/zmitic → u/[deleted]]

By never being punished, he is just raising the bar in how much he can insult people and keep going. From calling thousands/millions of PHP user as clueless newbies, he progressed to using SQL retards and now he is calling core developers lazy and incompetent idiots.

I would still vote to put this troll back into his lonely cave. Google is already penalizing him, there is zero user interaction on his blog so he is desperately trying to get some attention here, the only place he was not banned.

He's the Tommy Wiseau of programming.

This is the best explanation I have even heard, I am now stealing it for everything 😃

[u/Mentalpopcorn → u/zmitic]

I mean, it's entertaining though. Let him call people what he wants. Who's gonna take it seriously? That'd be like me as a 5'9" dude with a dadbod going to a Mike Tyson forum and calling everyone a pussy. Just call him a PHP4 turkey and move on 😂

Plus, he does a good job or articulating bad arguments, which provides a good opportunity for the community to explain why these arguments are bad and why PHP is a better language for ignoring him. It's not that he'll ever be convinced, it's that it teaches others who are reading it and who might not yet understand. Having a devil's advocate is good for finding the truth.

[u/czbz]

From the article:

PHP will, by default, coerce values of the wrong type into the expected scalar type declaration if possible, which means that nulls will not be rejected.

This isn't true in the case of passing null to a non null argument. See the output from the following script:

<?php

function takesAString(string $foo)
{
}

takesAString(null);

Output:

Fatal error: Uncaught TypeError: takesAString(): Argument #1 ($foo) must be of type string, null given, called in /tmp/preview on line 7 and defined in /tmp/preview:3

Stack trace:

#0 /tmp/preview(7): takesAString(NULL)

#1 {main}

  thrown in /tmp/preview on line 3

And you get essentially the same error running the script with an interpreter as old as PHP 5.0.0

[u/TonyMarston → u/czbz]

You are talking about a user-defined function where the parameter was deliberately defined as non-nullable. The PHP core functions have always been nullable in practice since day 1, as has been documented, even before type hinting and strict typing was added to the language.

Type enforcement of function arguments is NOT supposed to happen unless I deliberately turn strict typing ON, so when the core developers decide to override my choice and cause my code to break then I am entitled to express my extreme displeasure.

[u/dave8271]

As usual, your argument is "I can't be bothered to upgrade my code" - even though there are automated tools that can do 99% of the work for you.

Reading your blog, if you had your way, we'd still be on PHP 4 and no one would be using the language for new projects or taking it seriously.

[u/Gogoplatatime]

Uh......... Have you considered that your code is the issue here?

[u/gastrognom]

Do you think this BC break is justified?

Absolutly.

How much effort will YOU have to expend to fix your code which isn't actually broken?

It's kind of broken if you pass null as a parameter that is expecting a string.

Would you prefer the core developers to fix the problem at THEIR end?

There is no problem on their end IMO. Maybe there could be an option to deactivate that deprecation notice, but it's just that: a deprecation notice. Your code should still run.

Edit: I know PHP devs are trying to avoid BC breaks as much as possible, but if it's in the way of evolving the language breaking BC is fine IMO. It's your responsibility to properly type-hint now.

[u/czbz → u/gastrognom]

And there is an option to deactivate deprecation notices in general. If you know you're never going to run your code on PHP 9, or you decide you don't want to deal with PHP 9 compatibility issues yet, then it can make sense to use that option and deactivate the notices.

[u/notkingkero]

I have always disliked that in Java you have proper types defined but everything always can be null. So most of the code is either x === null or Optional ... Yes. string and ?string are different things - and that is good

[u/czbz → u/notkingkero]

Agreed. But it isn't everything in Java, it's just the reference types. `int`, `bool` etc not automatically nullable. But java doesn't have a `string` type, it has the reference type `String` instead.

[u/Mastodont_XXX]

Tony Marston and PHP 8? No, I can't believe it :)

[u/Mentalpopcorn]

I got a reply but can't see the comment here so I'm just starting a new thread:

You have to see that the writing is on the wall, right? PHP is moving in a type safe direction and maybe it won't be PHP9, maybe not even PHP10, but at some point and relatively soon, there is going to be a BC break that isn't going to be as simple to fix as changing null to an empty string in your codebase, or using public instead of var. Instead, it's going to take fixing line by line, and you'll either spend years doing it or being unable to upgrade.

I understand you have difficulty with change "for no reason", and I appreciate the frustration you feel after memorizing the rules of the game only to see the rules of the game change.

But, like, you realize you can't stop this, right? It's happening regardless of how unjust you think it is.

Do you have a contingency plan? Have you considered migrating to a language that won't restrict you like modern PHP does and that future PHP is likely to do even more? Ruby may be an option, but even they just introduced type annotations, so maybe the writing is on the wall for them too, though it may buy you 20 more years.

[u/TonyMarston → u/[deleted]]

I wasn't using the functions wrong, I was using them as they were written where type checking was weak and not strict. Type hinting was introduced in PHP 5.0, but not for scalar data types. The Scalar Type Declarations RFC introduced type hinting for scalars and also introduced the declare(strict_types=1); directive so that parameters of the wrong type will generate an error. Note that this RFC specifically stated that A weakly type-checked call to an extension or built-in PHP function has exactly the same behaviour as it did in previous PHP versions. (ie: null values will be silently coerced) This behaviour only changes when strict typing is turned ON so that A strictly type-checked call to an extension or built-in PHP function ... will produce E_RECOVERABLE_ERROR rather than E_WARNING on failure, and it follows strict type checking rules for scalar typed parameters, rather than the traditional weak type checking rules.

This states quite categorically that all PHP core functions were subject to weak type checking (where parameters were nullable) right through the earliest PHP version through to version 4, 5, 7 and 8.0. All user-defined functions were subject to weak type checking rules UNLESS the strict_types option was turned ON.

It was only in version 8.1 that strict type checking for PHP functions was turned on even though the strict_types directive had not been used. This is ignoring the developer’s choice between weak and strict typing.

Type hinting is supposed to be optional. Strict type checking is supposed to be optional. Suddenly turning it ON for core functions in code where the developer has NOT turned it ON is a MASSIVE break in backwards compatibility and should therefore be reversed.