6 minutes read
PHP 9.0: what we know about it
Written byTable of contents
- → Introduction
- → When will PHP 9.0 be released?
- → How to install and test PHP 9.0?
-
→
New features and changes planned for PHP 9.0
- → Better increment and decrement behavior
- → PHP 9.0 throws an exception on unserialization errors
- → Simplified function signatures
- → No more arrays out of false values
- → Simplified string interpolation
- → Some warnings will become errors in PHP 9.0
- → Deprecated features from earlier PHP versions will be removed
Introduction
PHP is an open-source project. Knowing what new features and changes are planned for the next version only takes a minute of research. For instance, this page lists all the accepted RFCs for different versions of PHP.
That being said, despite PHP 9.0 being planned, no work has been started yet and we have to dig deeper.
When will PHP 9.0 be released?
For now, the release date of PHP 9.0 hasn’t been announced yet. This version is still far in the future. We could get PHP 8.5 and 8.6 before 9.0 is even considered. Who knows?
How to install and test PHP 9.0?
To this day, no work has been started on PHP 9.0, so you won’t even be able to pull the latest code and compile it yourself.
New features and changes planned for PHP 9.0
Better increment and decrement behavior
PHP 9 is cleaning up how the ++ and -- operators work. Here’s what’s changing:
-
No more weird string increments:
// PHP 8 and earlier $foo = 'a9'; $foo++; echo $foo; // Outputs: 'b0' // PHP 9 $foo = 'a9'; $foo++; // Throws a TypeError
-
Booleans and null will be treated as numbers:
// PHP 8 and earlier $bar = true; $bar++; var_dump($bar); // Outputs: bool(true) // PHP 9 $bar = true; $bar++; var_dump($bar); // Outputs: int(2)
-
Empty strings won’t magically become numbers:
// PHP 8 and earlier $baz = ''; $baz--; var_dump($baz); // Outputs: int(-1) // PHP 9 $baz = ''; $baz--; // Throws a TypeError
These changes make PHP more predictable.
If you still need the old string increment behavior, you can use the new str_increment() function.
PHP RFC: Path to Saner Increment/Decrement operators
PHP 9.0 throws an exception on unserialization errors
This RFC, Improve unserialize() error handling, which has been partially implemented in PHP 8.3, upgrades unserialization errors from E_NOTICE to E_WARNING.
In PHP 9.0, these will be upgraded to an UnserializationFailedException.
This will allow developers to stop using a custom error handler and get a behavior more consistent with other parts of the language.
// PHP 8.3: "Warning: unserialize(): Error at offset 0 of 3 bytes" // PHP 9.0: "Uncaught UnserializationFailedException: unserialize(): Error at offset 0 of 3 bytes" unserialize("foo");
Simplified function signatures
PHP 9 is will make functions easier to understand and use. How? By simplifying their signatures. Let’s break it down with two examples.
First, take a look at array_keys():
// Current PHP: $allKeys = array_keys($myArray); $specificKeys = array_keys($myArray, 'searchValue', true); // PHP 9: $allKeys = array_keys($myArray); $specificKeys = array_keys_filter($myArray, 'searchValue', true);
See the difference? Instead of one function doing two jobs, we’ll have two separate, more focused functions.
Here’s another example with DatePeriod::__construct():
// Current PHP: $period1 = new DatePeriod($start, $interval, $end); $period2 = new DatePeriod('R4/2012-07-01T00:00:00Z/P7D'); // PHP 9: $period1 = new DatePeriod($start, $interval, $end); $period2 = DatePeriod::createFromISO8601String('R4/2012-07-01T00:00:00Z/P7D');
Again, we’re moving from one multi-purpose constructor to a constructor and a separate creation method.
Why these changes? They make PHP more predictable. When a function or method does just one thing, it’s easier to understand and use correctly.
Here’s the plan:
- PHP 8.3 introduces the new functions.
- PHP 8.4 warns you about using the old ways.
- PHP 9 (or 10, it’s still not decided) will complete the transition.
PHP RFC: Deprecate functions with overloaded signatures
This RFC proposes to deprecate and eventually remove autovivification (automatic creation of arrays) from false values in PHP. Here’s a simplified explanation for the blog post:
No more arrays out of false values
PHP 9 is getting stricter about how arrays are created, particularly when it comes to false values. Let’s break this down:
Currently in PHP, you can do something like this:
$arr = false; $arr[] = 2; // This creates an array [2]
This feature, called “autovivification”, automatically converts false to an array. While convenient, it can lead to unexpected behavior and bugs.
In PHP 9, this won’t be allowed anymore. Instead, you’ll see an error:
$arr = false; $arr[] = 2; // Error: Cannot use a scalar value as an array
You already can’t do this with other values like true or 0, so why should false be special?
PHP RFC: Deprecate autovivification on false
This RFC proposes to deprecate and eventually remove certain forms of string interpolation in PHP. Here’s a simplified explanation for the blog post:
Simplified string interpolation
PHP 9 is simplifying how you can embed variables in strings. Let’s break it down:
Currently, PHP allows several ways to put variables inside strings:
- Direct:
"$foo" - Braces outside:
"{$foo}" - Braces after dollar:
"${foo}" - Variable variables:
"${expr}"
PHP 9 will keep options 1 and 2, but remove options 3 and 4. Why? Because they’re confusing and less useful.
For example, this won’t work in PHP 9:
$foo = 'world'; echo "Hello ${foo}"; // This will cause an error
Instead, you’ll need to use one of these:
echo "Hello $foo"; // Option 1 echo "Hello {$foo}"; // Option 2
PHP RFC: Deprecate ${} string interpolation
Some warnings will become errors in PHP 9.0
In order to make PHP more reliable, warnings for undefined variables and properties will now become errors.
For instance, the following code will not run anymore in PHP 9.0:
// PHP 8.x: "Warning: Undefined variable $foo" // PHP 9.0: "Fatal error: Uncaught Error: Undefined variable '$foo'" echo $foo;
Also, from what I understand, these changes with variables and properties will make the maintainers’ lives easier, which is good for everyone!
I let you check out the RFCs for more details:
Deprecated features from earlier PHP versions will be removed
Features that have been deprecated in PHP 8.1, 8.2, 8.3, and 8.4 (learn more about PHP 8.4) will finally be removed in PHP 9.0. This will translate to breaking changes for developers who ignored the warnings. 😅
Here’s a list of RFCs containing all the deprecated features:
- PHP RFC: Deprecations for PHP 8.1
- PHP RFC: Deprecations for PHP 8.2
- PHP RFC: Deprecations for PHP 8.3
- PHP RFC: Deprecations for PHP 8.4
Did you like this article? Then, keep learning:
- Detailed features and release info about the upcoming adjacent PHP version
- Best PHP blogs to help keep updated with PHP versions and changes
- Guide to check your PHP version, useful before upgrading to PHP 9
- Overview of the latest PHP 8.3 release, precursor to PHP 9.0
- Learn PHP array manipulations, complementing new PHP 9 array behavior changes
- Discusses PHP autoloading and packages, aiding PHP environment management
- Explains error handling improvements, related to PHP 9's exception upgrade
- Help to print and debug PHP arrays, relevant for testing PHP 9 changes
- Preview of PHP 8.5 features, expected before PHP 9.0 release
18 comments
What would you expect from PHP 9? PHP 8 seems quite mature already. I think they are yet collecting breaking ideas for PHP 9.
I'm open to big changes! Some people might not, though. It's really hard to see where it's going for now, unfortunately.
What I expect from PHP 8:
Why explicit typing for a variable that's obviously an integer? We have other languages that can do that and even they push implicit typing (which IDEs support very well).
Will PHP 9 support Async/Await mode and will PHP 9's concurrency be perfected and available? May I ask why ruby node these languages, have perfect asynchrony, why PHP so long, already to keep up with the pace of the times, so far there is no perfect asynchrony or coprocessing? Is it because of the development of third-party libraries that some people are deliberately slowing down the progress of PHP asynchrony?
I have no idea why PHP is on the trajectory it is now. That being said, it works well and the language's popularity speaks for itself. But maybe you should take a look at ReactPHP if you really need this?
Thank you! Why can't PHP itself suppose these new asynchronous features, but suggests that people go to third party projects. Is the launch of the PHP poll controlled by someone? Is it possible that PHP's organising committee is no longer democratic and has been controlled by a dictatorship for profit?
Sorry for the very late reply, haha. FYI, PHP hardly makes any profit and it's not dictatorship. Each new feature is voted. Also, some feature why require tremendous unpaid work.
it’s magnificent and awesome; what makes the power of a language is not its speed or the number of people who train its environment and its use but the stable logic of its use of course many other languages offer facilities and visions of the code exceptional and they must exist to offer solutions to PHP so that PHP can become the best of itself little by little. in its field PHP going too fast is a disadvantage and a danger for many professions. the world of Dev needs stability and not to move forward too quickly. to create solid and powerful foundations.
So, are you just making this up? PHP should be rewritten in Rust.
Yep, totally made this post up and eagerly waiting for a Rust rewrite as well!
To be honest, I don't really care about the "shiny new increment" and other minor improvements. What I'd really like to see is proper support for generics — at the class level, not just in type annotations. How about finally implementing asynchronous programming features?
I respect the language developers a lot, but in my opinion, a major release should include changes significant enough to convince my management to allocate resources for upgrading. Right now, what I mostly see are questionable or minor improvements.
If you read the article, you can see that there's no code written for PHP 9 yet.
What we know about it is small bits from RFCs for PHP 8.x that couldn't fit because of breaking changes. (They're linked every time.)
The big features will come when PHP 9 reaches active development.
You, yourself, and your management will be pleased at some point, promise!
I seriously think that php organising committee are infested of java programmers and are trying to tranform php 9 or 10 in some weird flavour of java... We like php because its a come in handy tool and dont stop the whole process on the middle because minor warnings or insignificant shit that happens.. The more important is go til the end in such a failproof language that if cant show whole information because some bug, at least show partial information. But now they are trying to do a foolproof language... Fools doesnt know that they are doing and we dont need so foolish protections against ourselves. Best go back and program on C. Organising committee democratic vote acts like Bolsheviks... Should ask community to vote for some big changes that destroying code retrocompatibility...
Sorry but this is a really bad take that isn't based on any evidence. Please read the full article so you understand what's going on with PHP 9. This is still an unannounced release.
Woow
do you know any performance bechmarks? like how faster will it be?
Like I said in the article, nobody has written a line of code for it yet. Only some features are planned.