PHP 8.5 language changes since PHP 8.4

PHP 8.5 adds the pipe operator |>. The expression on the left is passed as the single argument to the callable on the right, and the result flows into the next stage. First-class callable syntax such as trim(...) fits naturally, so a transformation that used to be written inside-out can now read in execution order.

Each stage must be a callable that accepts one argument, so functions needing extra arguments have to be wrapped in a closure or arrow function. Wrap an arrow function in parentheses when you place it in a chain, otherwise the parser cannot tell where the function body ends. Because every stage hands exactly one value to the next, the pipe works best for small, pure transformations.

The pipe does not change what the functions do; it only changes how you write the composition. Be aware that none of this syntax parses on PHP 8.4 or earlier, so adopt it only once 8.5 is your minimum version. Keep chains short enough to read, and extract named functions when a stage gets complicated.

In PHP 8.5, clone behaves like a function and accepts a second argument, $withProperties, an array of property names and new values applied to the copy. The manual notes that this also lets you reassign readonly properties during cloning, which was previously awkward because readonly properties could not be modified after initialization.

This makes immutable "with-er" methods much shorter. Instead of calling the constructor again and repeating every unchanged argument, you clone the object and name only the properties that differ. Adding a new property to the class no longer requires updating every with-er method.

The pitfall is that you now have two ways to build modified copies, so keep your team's convention consistent. The override array uses property names as keys, so a typo in a key is a runtime issue rather than a compile-time one; cover with-er methods with tests. The function-call form of clone is PHP 8.5 only.

PHP 8.5 adds the #[\NoDiscard] attribute for functions whose return value is important. If a caller invokes such a function as a bare statement and throws the result away, PHP emits a warning. Using the value, for example by assigning it, silences the warning.

The companion (void) cast documents that ignoring a value is intentional. By itself it has no effect on how the program runs, but it suppresses the #[\NoDiscard] warning and may also quiet diagnostics from IDEs and static analysis tools.

This is most useful on functions that report success or failure through a return value rather than an exception. The migration risk is limited to code you annotate yourself, or to attributed functions you call, since a bare call to such a function now produces a warning. Do not sprinkle (void) everywhere; it should mark the few places where discarding really is deliberate. On PHP 8.4 the attribute is just an unused attribute, but the (void) cast is a syntax error.

PHP 8.5 allows closures and first-class callable syntax inside constant expressions. According to the manual, that covers attribute parameters, default values of properties and parameters, and both global and class constants.

The practical gain is that a parameter can have a real callable default. Before, you had to default to null and substitute the fallback inside the function body, which hid the default from the signature and from reflection. Now the default is declared right where the parameter is.

A closure used in a constant expression has to be self-contained: write it as static, since there is no object for it to bind to. Arrow functions (fn) are rejected in constant expressions with a fatal error; use a static function closure instead. Also remember that a constant holding a closure must be copied into a variable before you call it, because writing the constant name followed by parentheses is a function call. As with all new syntax, this does not parse on PHP 8.4.

Asymmetric visibility, which PHP 8.4 offered for instance properties, now extends to static properties in PHP 8.5. A declaration such as public private(set) static int $count lets any code read the value while only the declaring class can write it.

This suits shared counters, registries and other class-level state where outside code needs read access but must not modify the value directly. It replaces the older pattern of a private static property plus a public static getter, which was more code and less obvious.

When outside code attempts a write that the write visibility forbids, PHP throws an Error, so tests should cover any code that previously assigned such a property from outside. The write scope you choose applies to everything outside it, including subclasses if you pick private(set). Pick protected(set) when subclasses need to update the value. The syntax is not available on PHP 8.4 for static properties.

The #[\Override] attribute previously applied to methods, where it makes PHP complain if nothing in a parent class or interface is actually being overridden. In PHP 8.5 it can also be attached to properties.

This catches a common refactoring accident: a parent property is renamed or removed, and a child class's redeclaration silently becomes a brand-new, unrelated property. With the attribute in place, the engine reports an error instead, so the mismatch is found at once rather than through odd behaviour later.

The attribute does not change the value or visibility of the property; it only states intent and enables the check. Add it to child-class property redeclarations such as changed defaults. If a property is marked but the parent does not have it, expect a fatal error, so apply it deliberately. On PHP 8.4, using it on a property is not valid.

Constructor property promotion lets you declare and assign a property in the constructor signature. Until PHP 8.5 you could not combine it with final, so a property that subclasses must not redeclare needed a separate declaration plus a manual assignment.

Now the modifier can sit directly on the promoted parameter. The class itself does not need to be final; only the property is protected from being overridden in child classes. This keeps the constructor signature as the single place that describes the property.

The migration impact is small: existing code keeps working, and you can tidy classes that used the longer pattern. Remember that a final property still has to be declared with a visibility that subclasses can see, and that this syntax is a parse error on PHP 8.4, so do not use it in code that must still run there.

PHP has long accepted alternative spellings for its scalar casts. In PHP 8.5, (boolean), (integer), (double) and (binary) are deprecated. The replacements are the canonical forms: (bool), (int), (float) and (string).

The code still runs on 8.5, but each use emits a deprecation, which will be noisy in logs and fatal if your error handler converts deprecations into exceptions. The fix is mechanical, so it can be done with a search and replace or an automated refactoring tool such as a code-style fixer, then checked by the test suite.

Pay attention to (binary), which is the least obvious: it maps to (string). The canonical casts work identically on PHP 8.4 and 8.5, so you can make this change before you upgrade and it is safe on both versions. Also search vendored code and templates, since the deprecation fires wherever the cast is compiled.

PHP has historically tolerated a semicolon after a case label in a switch, treating it like the usual colon. PHP 8.5 deprecates that form. The code still behaves the same, but it now emits a deprecation message when the file is compiled.

This is usually found in very old code or in hand-edited legacy files, and it is easy to miss because it never caused a visible problem. A project-wide search for case lines ending in a semicolon is a quick way to find candidates, and a syntax linter run under PHP 8.5 will report them as well.

Changing the semicolon to a colon is safe on every supported PHP version, so you can fix it ahead of the upgrade. Since the deprecation is raised at compile time, it can appear for files that are never executed in a given request, for instance when they are loaded through an autoloader. Check the default label too if it was written the same way.

PHP silently converted a null array offset to the empty string key. PHP 8.5 deprecates that implicit conversion, both for ordinary offsets and when null is passed as the key to array_key_exists(). The manual's recommended replacement is an explicit empty string.

The risk is in code where the key comes from a variable that may be null, such as an optional lookup value or an unset form field. These paths may only run in rare cases, so the deprecation can appear late in production logs. Decide whether a missing key should really map to the empty-string entry. If it should not, handle the null case separately instead of papering over it.

When you do want the old behaviour, make it visible with the null coalescing operator, which works on every PHP version. Static analysis that tracks nullable types is the best way to find these spots before upgrading, because the dynamic behaviour only shows up when the null value actually reaches the array access.

PHP 8.5 emits a warning when a float, or a string that looks like a float, is cast to int and cannot be represented as one. This covers explicit (int) casts and implicit conversions. Casting NAN to other types also warns now.

Previously these conversions gave a meaningless result without any signal, so a bad value could travel through a program unnoticed. The warning exposes those cases, but it can also surface in code that appeared to work, particularly arithmetic that overflows into very large floats or parsing of untrusted numeric input. Be especially careful if you convert warnings to exceptions.

The robust fix is to check the range before casting and decide explicitly what a non-representable value should mean, such as returning null or rejecting the input. Ordinary fractional values such as 42.9 are still truncated by an explicit cast without any warning. The range check below also rejects NAN and infinity because comparisons with them are false.

Destructuring with [] or list() has always been forgiving: if the right-hand side was a scalar, the variables simply became null. PHP 8.5 emits a warning when you destructure a non-array value, with null still allowed without a warning.

This matters for code that destructures the result of a function with a loose return type, such as a parser returning false on failure or a lookup returning an integer. Such calls used to produce silent nulls and now log warnings, and with a strict error handler they become exceptions.

The fix is to validate the value before destructuring. Check with is_array() and supply an explicit fallback, or change the function to return a consistent array or null. Do this rather than suppressing the warning, because the warning points to a path that is probably unhandled. Because the behaviour change is only a diagnostic, the guarded form below runs identically on PHP 8.4 and 8.5.