PHP 8.5 is on the way: the maturing face of the language

PHP 8.5 hasn’t been released yet — I’m writing this in August 2025, and the release is expected toward the end of the year. But for those who follow the RFC process, the picture taking shape is fairly clear. I want to use this post to think through where PHP is heading with this release, and what the road it has traveled so far has taught us.

I’ve been writing PHP since 2008. Over that time I’ve watched the language’s transformation from the inside: from the OOP revolution of PHP 5, through the performance leap of PHP 7, to the attributes and match expressions of PHP 8.0, and on to the enums and readonly properties of 8.1. Each release looks small on its own, but the cumulative effect is enormous.

The arc of the 8.x series

PHP 8.0 marked the beginning of a genuine character shift in the language. Union types, the nullsafe operator, match expressions, and JIT (Just-In-Time) compilation arrived together as a major renovation package.

8.1 strengthened class modeling with readonly properties and enums. Writing immutable data structures at the language level in PHP finally felt natural for the first time.

8.2 brought readonly classes and DNF (Disjunctive Normal Form) types. 8.3 followed with practical additions like typed class constants and json_validate().

In 8.4, property hooks and asymmetric visibility took center stage. This feature fundamentally changed how we write getters and setters — reducing boilerplate while improving clarity.

What is taking shape in 8.5

Several proposals stand out in the RFC process. Nothing is finalized yet, but given the trajectory of discussions, they look probable.

Discussion around the pipe operator (|>). This operator, familiar from F# and Elixir, opens the door to writing function chains in a readable left-to-right style. I can see the PHP community still hasn’t reached consensus on this; the tension between expanding the language surface and preserving simplicity shows up here too.

Lazy initializer improvements. New proposals building on the lazy object support introduced in 8.4 could make it possible to control object initialization cost with even finer granularity.

Additions to the array_* function family. PHP’s array API is rich, but certain common operations still require too many lines of code. array_find() and array_find_key() are on the table to fill that gap.

The shape of a language’s maturity

There is now a clear pattern in PHP’s evolution: not big surprises, but consistent, incremental improvements. That is the hallmark of maturity.

Early in a language’s life, every major release can shift paradigms. In a mature language, those changes become subtler, more deliberate. Backward compatibility gains priority; keeping millions of lines of code running becomes more important than absorbing radical innovations.

PHP treads this balance carefully. Every release contains breaking changes, but they are announced in advance and the deprecation process is managed thoughtfully. With PHP 8.5, the removal of functions deprecated back in 8.0 is expected — this cleanup routine is itself part of the language’s maturity.

The deepening of the type system

The area where PHP has invested most consistently over its last several releases is the type system. With each version, types become more powerful and more expressive. The concrete payoff: static analysis tools — Psalm and PHPStan in particular — can now catch a large share of bugs in PHP code before it ever runs.

// PHP 8.x's type expression capacity
function processResult(int|string $id): User|null
{
    // ...
}

// Immutable models with readonly
readonly class Money
{
    public function __construct(
        public readonly int $amount,
        public readonly string $currency,
    ) {}
}

This code was not possible in PHP five years ago. Now it looks right at home, both in language syntax and in tooling support.

I can do a proper assessment of where PHP is heading once 8.5 ships. But what I can say already: the language I started with in 2008 and the language I write today are the same language — and yet, in terms of features and tooling, almost unrecognizable. That is a good thing.