PHP 7.1 language changes since PHP 7.0

Before 7.1 there was no way to say that a function returns either a string or null. Return types had to be left off, and parameters had to use a = null default, which also made the argument optional. PHP 7.1 lets you write ?string, meaning the declared type or null, for both parameters and return types.

A nullable parameter is still required: ?string $name accepts null only when you pass it explicitly. Calling the function with no argument at all still fails with an ArgumentCountError. If you want the argument to be omittable, you must still give it a default value.

The feature is most valuable for lookup-style functions that legitimately return nothing, because the signature now documents that callers must handle null, and the engine enforces that nothing else sneaks through. When migrating, replace docblock-only hints and the type $x = null trick with the explicit ?type form where the argument is genuinely required.

PHP 7.1 introduces void as a return type for functions that exist purely for their side effects. A void function may omit return entirely or use an empty return;. Returning null explicitly, or returning any value, is not allowed.

The benefit is documentation that the engine checks: readers and static analysis tools know the result is meaningless, and an accidental return $value; is rejected. Reference parameters, as in a swap helper, are a typical use.

A subtle point is that using the result of a void function does not emit a warning; the expression just evaluates to null. The language avoids warnings here so that generic higher-order code, which may pass any callable around, keeps working. Also remember that void is only valid as a return type, not as a parameter type, and that it cannot be combined with a nullable marker.

In PHP 7.0, calling a user-defined function with too few arguments produced a warning, and the function body still ran with the missing parameters unset. That meant bugs could slip through as logged warnings while the code carried on with null values.

Starting with 7.1 the warning is promoted to an Error exception, specifically ArgumentCountError, so the call stops immediately. Uncaught, it is a fatal error. This applies to user-defined functions only; internal functions were not changed by this item.

During migration, the practical risk is old code that was sloppy about arguments and relied on the warning being ignored or silenced. Turn on full error reporting in a 7.0 environment first and fix every "Missing argument" warning you find. Do not paper over the new exception by catching it broadly; supply the argument or give the parameter a default value.

Before 7.1, list() only worked with positional integer keys starting at zero. Unpacking an associative row meant a series of manual array reads. PHP 7.1 lets you specify keys inside list() or the new bracket shorthand, which handles string keys and non-sequential integer keys.

This is especially pleasant in foreach loops over database-style rows, where you can name just the columns you care about and ignore the rest. Keys are looked up directly, so the order inside the pattern does not need to match the order in the array.

A pitfall: you cannot mix keyed and unkeyed entries in the same pattern. If a key is missing from the source array, the target variable becomes null, and PHP raises a notice or warning about the undefined key depending on the version, so only destructure keys you know exist.

PHP 7.1 makes array literals symmetric: the [] syntax you already use to build arrays can now also take them apart. It works in plain assignments and as the loop target in foreach, and list() remains fully supported, so there is no need to rewrite existing code.

The main benefit is readability and consistency. A pattern such as [$id, $name] mirrors the shape of the data, and swapping two variables becomes a one-liner because the right-hand array is built before the assignment happens.

A migration caution is that code using [] on the left side will not parse on PHP 7.0, so adopting it raises your minimum version. Also keep in mind that destructuring is positional unless you add keys, so the number and order of elements still matters.

Until 7.1, every class constant was effectively public. Anything you defined as a constant could be read from anywhere, so internal magic numbers and keys became part of the public API by accident. PHP 7.1 allows public, protected and private modifiers on constants.

A constant declared without a modifier remains public, so existing classes keep working. Private constants are visible only inside the declaring class, and protected ones also to subclasses. Reading a non-visible constant from outside throws an Error.

When upgrading, review classes that expose helper constants and decide which of them are really part of the contract. Tightening visibility is a breaking change for any caller that was relying on a constant, so do it deliberately, and remember that interface constants remain public.

Functions that just loop over their input often accept either an array or an iterator or generator, but 7.0 could not express that in a type declaration. PHP 7.1 adds iterable, a pseudo-type that matches arrays and any object implementing Traversable. It can be used for parameters and return types.

Inheritance rules follow the idea of substitution. A child class may widen a parent's array or Traversable parameter to iterable, and may narrow a parent's iterable return type to array or a Traversable implementation.

There is a compatibility catch: iterable (like void) can no longer be used as a class, interface or trait name. Search your codebase for any class with that name before upgrading. Also remember that iterable only guarantees you can loop once; generators cannot be rewound after they start.

When two unrelated exception types need the same handling, PHP 7.0 forced you either to duplicate the catch body or to catch a broad common parent and risk swallowing more than intended. PHP 7.1 lets you list several classes in a single catch, separated by the pipe character.

The variable receives whichever exception was actually thrown, so you can still inspect its class or message. Matching is the usual instanceof check against each listed type, in any order.

This is purely additive, so it is safe to adopt incrementally. It is a good fit for cleanup, logging, or translating different low-level failures into one domain error. Avoid listing a class together with its own subclass, as that is redundant, and remember that code using the syntax will not parse on PHP 7.0.

PHP 7.1 interprets a negative string offset as a position counted from the end of the string, so -1 is the last character. This works with square-bracket indexing and also in the simple variable syntax inside double-quoted strings. The release also extends it to string functions that take offsets, which belong to the library side of the release.

Previously you had to compute the position yourself from the string length, which was both noisy and a common source of off-by-one mistakes. With the new behavior, the last or second-to-last character is a direct read.

Two pitfalls remain. An offset that reaches before the start of the string is still out of range, so do not assume negative offsets are always safe. Also, the older curly-brace form of string offsets was later removed from the language in PHP 8.0, so prefer square brackets.

In PHP 7.1, a return; statement without a value inside a function that declares a return type triggers a compile-time fatal error, unless the declared type is void. The check happens when the file is compiled, so it applies even if that particular return statement could never be reached at runtime.

This matters because such code could previously sit unnoticed in a rarely used branch. After upgrading, the whole file fails to load, which makes the problem impossible to miss but also means a single bad line can take down a request.

The fix depends on intent. If the function should sometimes produce nothing, declare a nullable return type and write return null; explicitly. If it never produces a value, declare it void. Scan typed functions for bare return; before deploying.

Some built-in functions look at or modify the variables of the calling scope. Calling them indirectly, for example through $func() or by passing the name to array_map(), makes it unclear which scope they would act on, so PHP 7.1 forbids it. The affected functions include compact(), extract(), func_get_args(), func_get_arg(), func_num_args() and get_defined_vars(). A few others are restricted only in certain forms: assert() with a string argument, and parse_str() and mb_parse_str() with one argument.

Attempting a dynamic call now yields a warning that the function cannot be called dynamically, rather than doing something unreliable.

The replacement is simply to call the function directly, by name, in the scope that you want it to inspect. If you were building generic helpers around these functions, restructure them to pass arrays explicitly instead of relying on the caller's scope.

In PHP 7.0, an empty string was silently treated like an empty array when you assigned to an offset, so $a = ''; $a[10] = 'foo'; produced an array with one element. PHP 7.1 removes that special case. The empty string now behaves like any other string: writing beyond its end pads it with spaces, non-integer offsets are converted to integers, and only the first character of the assigned value is used.

This can quietly change data shapes. Code that started from an empty string and relied on getting an array out will now produce a string, and later array functions or foreach loops may misbehave.

If you want an array, initialize it with []. If you want to build a string, use concatenation. Assign a single character when you really mean to write one position, because later PHP versions warn when a longer string is assigned to an offset.

The empty index operator, written [] with no key, appends to an array. In PHP 7.0, applying it to a string quietly converted the variable into an array, which was almost never what the author intended and could hide type bugs. PHP 7.1 turns this into a fatal error.

The fix depends on what you wanted. To add text to a string, use concatenation with .=. To collect a list of items, start from an array and append with []. Because the failure is fatal rather than a warning, it is worth grepping for [] = on variables that might hold strings, especially ones initialized as '' and later appended to.

Running the test suite on 7.1 with full error reporting will surface the remaining cases quickly, because the engine now stops instead of changing the variable's type.

Integer operations and conversions on numerical strings now respect scientific notation. This covers the (int) cast, intval() with base 10, settype(), and the base-conversion helpers decbin(), decoct() and dechex().

In PHP 7.0, a string like '1e3' converted to the integer 1, because parsing stopped at the letter. In 7.1 it converts to 1000. That is arguably what a reader expects, but it is a silent behavior change: values read from forms, CSV files or configuration that happen to look like exponent notation will produce different integers after the upgrade.

When you migrate, check places where strings that may contain an e are cast to int, such as product codes or identifiers that are all digits with a single letter e in the middle. If such values are identifiers rather than numbers, keep them as strings and do not cast them.