PHP 8.0 language changes compared with PHP 7.4

In PHP 7.4, a non-strict comparison between an integer and a non-numeric string converted the string to a number, which turned every such string into zero. That is why 0 == "foo" and 0 == "" were both true. PHP 8.0 instead casts the number to a string and compares the two strings whenever the string is not numeric. Comparisons with genuinely numeric strings, including ones with leading whitespace such as " 42", still work numerically, and trailing whitespace is now allowed too.

The practical risk is code that relied on the old coincidence: in_array, switch and == checks against user input or database values can quietly flip their result. Review them and prefer === or explicit casts when you mean a type-sensitive check. Also note that "42foo" is no longer treated as equal to 42.

PHP 8.0 adds match, an expression form of branching. Unlike switch, it produces a value you can return or assign directly, has no fall-through and needs no break. Arms can list several comma-separated conditions, and a default arm covers the rest. Comparison is strict, so match does not apply the loose-comparison quirks that switch does. If no arm matches and there is no default, PHP raises an error rather than silently continuing.

A common idiom is match (true) with boolean conditions, as in the example, which replaces long if/elseif chains that only select a value.

One migration pitfall: match is now a reserved keyword, so you cannot use it as a function-style identifier for new declarations of classes, constants in the global namespace, or similar names. Rename any existing symbol called match before upgrading.

PHP 8.0 lets you pass an argument by writing the parameter name followed by a colon. This removes the need to repeat default values just to reach a later optional parameter, and it makes calls with several booleans or similar values readable. In the example, selfClosing: true is given without supplying $attrs at all.

A few things to remember. Positional arguments must come before named ones. Because names are now part of how callers use your function, renaming a parameter in a library can break callers, so treat parameter names as public API. A related behavior change: when you call call_user_func_array() with an array that has string keys, those keys are now interpreted as parameter names instead of being silently ignored, so check any code that passes associative arrays there.

With constructor property promotion, adding a visibility modifier to a constructor parameter both declares a property of that name and assigns the argument to it. A typical value-object class shrinks from three repetitive parts (property declaration, parameter, assignment) to one signature. Defaults work as usual, and you can mix promoted and ordinary parameters.

There are pitfalls. Promotion is only available in constructors, so it does not apply to ordinary methods. The property type comes from the parameter type, so a parameter without a type produces an untyped property. Remember that the constructor must be named __construct: methods named after the class are no longer treated as constructors in PHP 8.0.

The example also benefits from the Stringable interface, which PHP 8.0 adds automatically to any class that defines __toString().

Before PHP 8.0 you could only declare a single type (optionally nullable), so "int or float" had to live in a docblock. Union types let you write int|float in parameter, return and property declarations, and the engine enforces them. PHP 8.0 also adds the mixed type, which says a value can be anything and makes that intent explicit instead of omitting the type.

Two migration notes. mixed is now a reserved word, so you cannot name a class, interface or trait Mixed, nor use it in namespaces. Also, a default value that resolves to null at runtime no longer makes a parameter type implicitly nullable; write ?int or give an explicit = null default.

Union types make wrong inputs fail early, but remember that in non-strict mode scalar values may still be coerced into one of the allowed types.

The nullsafe operator ?-> stops evaluating a chain as soon as the value on its left is null and returns null for the whole chain. This replaces nested !== null checks when walking through optional relationships, such as a user who may have no profile.

It combines naturally with ?? to provide a fallback, as in the example. The short-circuit covers the rest of the chain, so later method calls in that chain are not executed when an earlier link is null, which also means side effects in those calls are skipped.

Be careful not to use it to hide data that should never be missing. A silent null can postpone a bug to a later, harder-to-trace place. Use it for genuinely optional values, and keep explicit checks or exceptions for required ones.

In PHP 7.4 throw was a statement, so you could not use it where an expression was required. PHP 8.0 makes it an expression. That allows compact guards like $value ?? throw new Exception(...) and arrow functions whose whole body is a throw, which is handy for default callbacks that must never be called.

PHP 8.0 also lets you write catch (Exception) without capturing the exception in a variable, which removes unused variables when you only care about the type of failure.

The main pitfall is readability: a throw hidden in the middle of a long expression is easy to miss, so keep such expressions short. Also remember that with ?? the throw only runs when the left side is null or unset, not for other falsy values such as an empty string.

PHP 8.0 makes the arithmetic and bitwise operators (+, -, *, /, **, %, <<, >>, &, |, ^, ~, ++, --) consistent: if an operand is an array, a resource or an object without operator overloading, a TypeError is thrown. Previously some operators quietly converted such values to numbers.

The one exception is array + array, which still merges arrays, as the last call in the example shows. Code that accidentally multiplied or added an array, for example because a function returned an array instead of a number, will now fail loudly rather than producing a wrong figure.

This is part of a wider tightening in PHP 8.0, where many warnings became Error exceptions and many notices became warnings, such as reading an undefined variable, property or array key. Run your tests with all errors enabled to find these before deployment.

In PHP 7.4 the concatenation operator had the same precedence as addition and subtraction, evaluated left to right. An expression like "Sum: " . $a + $b therefore concatenated first and then tried to add $b to the resulting string, which produced a wrong result and a warning. In PHP 8.0 arithmetic binds tighter than concatenation, so the sum is computed first and then appended, which is almost always what the author intended.

The risk is the reverse: code that was accidentally relying on the old grouping now behaves differently without any error. Search for lines that mix . with +, -, << or >> and add explicit parentheses. Parentheses make the intent obvious and give identical results on both 7.4 and 8.0, so you can apply them before upgrading.

An unparenthesized chain such as $s >= 90 ? 'A' : $s >= 80 ? 'B' : 'C' was accepted by PHP 7.4, even though it is easy to misread because PHP's ternary operator was left-associative, unlike most languages. PHP 8.0 rejects the construct outright, so the file will not compile.

The fix is mechanical: add parentheses around the inner ternary, as in the example, which keeps the meaning most people expect. For longer chains, a match (true) expression is often clearer, and an if block is fine when branches are complex.

Because this is a compile-time error, it takes down the whole file, not just the code path that uses it. Scan the codebase, or lint every file with php -l on PHP 8.0, before deploying the upgrade.

The old alternative syntax for offset access, $array{0} or $string{"key"}, has been removed in PHP 8.0. Square brackets have always been the primary syntax and behave identically, so the fix is a simple replacement of {} with [].

Because the old form is a syntax error on PHP 8, any file that still uses it will fail to load. Search legacy code, templates and vendored libraries, especially older string-manipulation helpers. Static analysis and php -l on PHP 8.0 will report each occurrence.

The square-bracket form works on PHP 7.4 as well, so you can make the change before upgrading. Negative string offsets such as $word[-1] are also fine and return the last character.

If a parameter with a default value comes before a required parameter, the default can never be used, because callers must always supply the later argument and therefore the earlier one too. PHP 8.0 deprecates this signature. In most cases you can simply drop the default, which does not change behavior.

There is one allowed form: a typed parameter with a null default, like A $a = null, which implicitly makes the type nullable. PHP 8.0 still accepts it, but the recommended style is an explicit ?A $a. A later PHP release deprecates the implicit nullable form too, so adopting the explicit form now avoids a second round of changes.

If you really want callers to skip a parameter, reorder so optional parameters come last, and use named arguments to select among them, as shown below.

Sorting callbacks such as the one passed to usort() are expected to return a negative, zero or positive integer. Many PHP 7 programs returned $a > $b, a boolean, and it happened to work. PHP 8.0 deprecates callbacks that return true or false, and the replacement is the spaceship operator <=>, which returns exactly the integer the sort needs.

This matters more because sorting is now stable in PHP 8.0: elements that compare as equal keep their original order. A boolean callback cannot express "equal", so it can interact badly with that guarantee. The example sorts by length and shows equal-length items staying in input order. If results of sorting functions look different after the upgrade, check for callbacks that treat equal elements inconsistently.