PHP 8.3 language changes since PHP 8.2

In PHP 8.2, if you assigned a negative key such as -5 to an empty array and then appended with [], the new element received key 0. PHP 8.3 changes this so the next key is $n + 1, which here is -4. This makes negative starting keys behave like positive ones, where appending always continues after the highest integer key.

The danger is that nothing warns you. Code that builds arrays from negative offsets, for example sparse timelines or coordinate-based buckets, and later relies on the appended element living at key 0 will quietly produce different keys. Serialized output, array_keys() results and lookups by key can all shift.

The rule only applies when the array was empty before the negative assignment. Search for places that start an array with a negative key and then append, and write the key explicitly if you need a specific value. The example shows the new keys directly.

Before PHP 8.3, if a parent class used a trait with a static property and a child class also used that trait, the child could end up sharing the parent's static storage. PHP 8.3 treats the trait use as if you had written the static property directly in the child class. The child therefore gets its own separate property with its own initial value.

This matters for counters, registries and caches kept in static properties through a trait. Code that relied on a child updating the same value as its parent will now see two independent values, and nothing raises an error. The reverse also holds: code that was surprised by shared state may now behave as originally expected.

Audit traits that declare static properties and are used at more than one level of a class hierarchy. If you do want shared state, declare the static property on the parent class only, or access it through the parent class name explicitly. The example shows the parent holding 5 while the child starts its own counter.

PHP 8.3 starts cleaning up the quirky string behavior of ++ and --. Incrementing an empty string or a non-alphanumeric string now emits E_DEPRECATED, and decrementing an empty or non-numeric string does the same. Incrementing other non-numeric strings, the Perl-style 'a' to 'b' behavior, is only soft-deprecated: no diagnostic yet, but you should not write new code that depends on it. The manual points to str_increment() as the explicit replacement for that alphanumeric case.

The common real-world trigger is a counter initialized as an empty string, for example $count = '' followed by $count++. That used to produce the string '1' without complaint. The fix is to initialize numeric counters as integers.

The code still works on PHP 8.3, so the practical risk is log noise or a failing test suite that turns deprecations into exceptions. Search for increments on variables that may hold strings. The example uses an integer counter, which is correct on every version.

The argument-less forms of get_class() and get_parent_class() relied on implicit context: they returned the class where the code was written, or its parent. PHP 8.3 deprecates both forms because the same information is available directly through language syntax.

The replacements are explicit about which class you mean. Use self::class for the class where the code is declared, which is what get_class() with no arguments returned. Use static::class when you want the runtime class of the object, and parent::class for the parent name. Choosing between self and static is the main pitfall, because they differ in subclasses, and the old call always matched self. Check each call site for which behavior the surrounding code actually depends on.

The old calls still run on PHP 8.3 but emit E_DEPRECATED, so they are easy to find in logs after upgrading. The example prints both forms side by side for a subclass.

Until PHP 8.3, constants were the one part of a class without a type declaration. You can now write public const string LABEL = 'x' in classes, interfaces, traits and enums. The engine checks that the value matches the declared type, and a child class that overrides the constant must keep a compatible type.

This makes interface contracts stronger. An interface can state that a constant is an int, and every implementing class is held to it instead of just relying on documentation. It also helps static analysis tools and readers.

There are pitfalls. Code using this syntax does not parse on PHP 8.2, so adopt it only after every environment runs 8.3 or later. A typed constant cannot be declared static or with a type like void, and an override with an incompatible type is a fatal error at compile time. Also note that extension classes may declare constant types too, which can affect subclasses.

Renaming or removing a parent method used to leave a child's override silently orphaned: the child method simply stopped being called by the parent. PHP 8.3 adds the #[\Override] attribute to catch this. Put it on a method that is intended to override a parent method or implement an interface method, and PHP produces a fatal error at compile time if no such method exists.

The attribute is useful in refactoring, because a typo in a method name or an upstream library removing a method is reported when the class is loaded rather than discovered later through changed behavior.

Keep a few points in mind. The check is existence only; it does not compare signatures beyond the normal inheritance rules. The attribute can be used on methods but is not a substitute for tests. Because attributes are ignored by older engines, the syntax is harmless on PHP 8.2, but you only get the safety check on 8.3 or later. Constructors are exempt from the requirement.

Readonly properties in PHP 8.2 could not be modified after initialization, which made __clone() awkward: you could not deep-copy a readonly property that held an array or object. PHP 8.3 relaxes the rule so that readonly properties can be reinitialized during cloning, within the __clone() method.

This lets immutable value objects clone nested state, for example giving the copy its own array, a fresh collection or a cloned child object, without dropping readonly. The example appends an entry to a log in the clone and leaves the original untouched.

The permission is narrow. Only code running inside __clone() may reassign the property, so a regular with method that clones and then assigns still fails with an Error. The property must also be assigned from the class scope that declared it. Code relying on this syntax behavior only works on PHP 8.3 or later, while PHP 8.2 throws when you try to modify the property in __clone().

PHP 8.2 introduced readonly classes, but anonymous classes could not use the modifier. In PHP 8.3 you can write new readonly class(...) { ... }, and all declared properties become readonly, which is convenient for small inline value objects, test doubles and data carriers.

The usual readonly rules still apply. Every property needs a type, static properties are not allowed, and assigning to a property after construction throws an Error. Promoting constructor parameters keeps the declaration short, as in the example.

The main pitfall is compatibility: the syntax is a parse error on PHP 8.2, so you cannot ship it to mixed environments. When you print messages from errors on anonymous classes, remember that the generated class name contains extra characters, so avoid asserting on the full message in tests. The example only reports that the write was blocked.

Reading a class constant whose name is only known at runtime used to require constant('Class::NAME'), which builds a string and loses the readability of normal syntax. PHP 8.3 adds C::{$name}, where the braces contain an expression yielding the constant name. It works with the class name, with static, and with an object on the left, and it also reaches enum cases because they are class constants.

This is handy for mapping input such as a status string to an enum case or a configuration key to a constant, without a lookup table.

Be careful with untrusted input. A missing constant throws an Error, so validate or catch it when the name comes from users. Visibility rules still apply, so private constants remain private. The syntax does not parse on PHP 8.2, so keep constant() until all your environments have moved to 8.3 or later.

Static variables previously had to be initialized with constant expressions, so a value computed by a function call needed an awkward null check on every invocation. PHP 8.3 lets the initializer be any expression, including calls to functions, and PHP evaluates it once, the first time execution reaches the declaration.

This removes boilerplate in memoization helpers, lazily built lookup tables and ID generators. The example builds a prefix with strtoupper() and a starting number with intdiv() directly in the declarations.

There are a couple of cautions. The initializer runs at first use rather than at compile time, so side effects and exceptions happen then. A static variable in a method is also separate per class when inherited, as before. Code using non-constant initializers is a compile error on PHP 8.2, so the old guard pattern must stay until you drop support for it.

First-class callable syntax such as $obj->method(...) can wrap a method that does not exist but is handled by __call(). In PHP 8.3, the resulting closure accepts named arguments, and the extra names arrive in the magic method's $arguments array as string keys, just like a direct call to the magic method.

This matters for proxies, fluent builders and routers that forward calls and want to preserve the caller's argument names. Before this change, passing named arguments to such a closure failed, so forwarding code had to avoid them.

Watch the shape of the array: positional values have integer keys and named values have string keys, so code that assumes a list needs to handle both. The example encodes the received array as JSON to show the names. Because this relies on engine behavior added in 8.3, keep positional-only calls if you must also run on PHP 8.2.

A trait's methods become part of the using class, but until PHP 8.3 you could not change their modifiers to final when importing them. The as clause now accepts final, for example use Greets { hi as final; }. The method keeps its name and becomes non-overridable in subclasses of the class that uses the trait.

This is useful when a trait supplies behavior that must stay stable, such as a serialization hook, and you want to stop descendants from replacing it. Previously you had to wrap the logic in a final method of your own.

Subclasses that try to override the method trigger a fatal error at compile time, so you will see problems on load rather than at runtime. The syntax does not parse on PHP 8.2. The example checks the result with ReflectionMethod::isFinal() instead of triggering the fatal error.