Les property hooks

Pendant vingt ans, si on voulait du comportement à l’accès d’une propriété en PHP, il fallait écrire des getters et setters :

class User {
    private string $_name;
    
    public function getName(): string { return $this->_name; }
    public function setName(string $name): void {
        $this->_name = strtoupper($name);
    }
}

PHP 8.4 ajoute des hooks directement sur la propriété :

class User {
    public string $name {
        set(string $name) {
            $this->name = strtoupper($name);
        }
    }
}

On peut définir les hooks get et set indépendamment. Une propriété avec seulement un hook get est calculée à l’accès :

class Circle {
    public float $area {
        get => M_PI * $this->radius ** 2;
    }
    
    public function __construct(public float $radius) {}
}

Pas de stockage backing, pas de méthode getter explicite, support IDE complet. Les interfaces peuvent aussi déclarer des propriétés avec des hooks, ce qui signifie que les contrats peuvent maintenant spécifier un comportement à l’accès aux propriétés, quelque chose qui était tout simplement impossible avant.

La visibilité asymétrique

Une option plus légère pour quand on veut juste une lecture publique et une écriture privée :

class Version {
    public private(set) string $value = '1.0.0';
}

$v = new Version();
echo $v->value;      // fonctionne
$v->value = '2.0';  // Error

Élimine le pattern private $x + public getX() pour les propriétés publiques en lecture seule sans avoir besoin de la sémantique readonly complète.

array_find() et amis

$first = array_find($users, fn($u) => $u->isActive());
$any   = array_any($users, fn($u) => $u->isPremium());
$all   = array_all($users, fn($u) => $u->isVerified());

Ces fonctions existent dans la bibliothèque standard de chaque autre langage depuis des décennies. En PHP, il fallait utiliser array_filter() + accès par index ou écrire une boucle manuelle. Elles existent maintenant : array_find(), array_find_key(), array_any(), array_all().

Instanciation sans parenthèses supplémentaires

// avant
(new MyClass())->method();

// après
new MyClass()->method();

Une restriction syntaxique qui était toujours agaçante et jamais justifiée est supprimée.

Les objets paresseux

Des objets dont l’initialisation est différée jusqu’au premier accès à une propriété :

$user = $reflector->newLazyProxy(fn() => $repository->find($id));
// Pas d'appel en base encore
$user->name; // Maintenant le proxy s'initialise

Le public direct est les auteurs de frameworks ORM et de conteneurs DI, pas les développeurs d’applications. Mais l’effet se fait sentir dans chaque application qui utilise Doctrine ou Symfony : le lazy loading implémenté au niveau du langage plutôt qu’à travers la génération de code.

PHP 8.4 est un langage qui ressemble à peine au PHP 5 avec lequel la plupart d’entre nous avons commencé. Les property hooks en particulier : ce ne sont pas des contournements, ce sont une fonctionnalité de conception.

#[\Deprecated] pour son propre code

PHP émet des notices de dépréciation pour les fonctions intégrées depuis des années. 8.4 permet de câbler le même mécanisme dans son propre code :

class ApiClient {
    #[\Deprecated(
        message: 'Use fetchJson() instead',
        since: '2.0',
    )]
    public function get(string $url): string { ... }
}

Appeler une méthode dépréciée émet maintenant E_USER_DEPRECATED, exactement comme appeler mysql_connect(). Les IDEs le détectent, les analyseurs statiques le signalent, le log d’erreurs le capture. Avant ça, la seule option était un commentaire PHPDoc @deprecated : bien pour les IDEs, complètement invisible pour le moteur.

BcMath\Number rend la précision arbitraire utilisable

Les fonctions bcmath existent en PHP depuis toujours, mais leur API procédurale rend tout chaînage pénible. 8.4 ajoute BcMath\Number, un wrapper objet avec surcharge d’opérateurs :

$a = new BcMath\Number('10.5');
$b = new BcMath\Number('3.2');

$result = $a + $b;             // BcMath\Number('13.7')
$result = $a * $b - new BcMath\Number('1');
echo $result;                  // 32.6

Les opérateurs +, -, *, /, **, % fonctionnent tous. L’objet est immutable. L’échelle se propage automatiquement à travers les opérations. Les calculs financiers, qui nécessitaient des chaînes de bcadd(bcmul(...), ...), se lisent maintenant comme de l’arithmétique.

De nouvelles fonctions procédurales complètent le tableau : bcceil(), bcfloor(), bcround(), bcdivmod().

L’enum RoundingMode remplace les constantes PHP_ROUND_*

round() a toujours pris un $mode entier depuis un ensemble de constantes PHP_ROUND_*. 8.4 les remplace par un enum RoundingMode avec des noms plus propres et quatre modes supplémentaires qui n’étaient pas disponibles avant :

round(2.5, mode: RoundingMode::HalfAwayFromZero);  // 3
round(2.5, mode: RoundingMode::HalfTowardsZero);   // 2
round(2.5, mode: RoundingMode::HalfEven);          // 2 (arrondi du banquier)
round(2.5, mode: RoundingMode::HalfOdd);           // 3

// Les quatre nouveaux modes (disponibles uniquement via l'enum)
round(2.3, mode: RoundingMode::TowardsZero);       // 2
round(2.7, mode: RoundingMode::AwayFromZero);      // 3
round(2.3, mode: RoundingMode::PositiveInfinity);  // 3
round(2.3, mode: RoundingMode::NegativeInfinity);  // 2

Les anciennes constantes PHP_ROUND_* fonctionnent encore. L’enum est la voie à suivre.

Les fonctions de string multibyte qui auraient dû exister

mb_trim(), mb_ltrim(), mb_rtrim() : des fonctions de trim qui respectent les frontières de caractères multibyte, pas juste les espaces ASCII. Aussi nouvelles : mb_ucfirst() et mb_lcfirst() pour la mise en majuscule correcte des strings multibyte.

$s = "\u{200B}hello\u{200B}"; // Espaces de largeur nulle
echo mb_trim($s);              // "hello"
echo mb_ucfirst('über');       // "Über"

Ces fonctions comblent des lacunes présentes depuis que mbstring a été introduit.

request_parse_body() pour les requêtes non-POST

PHP parse automatiquement application/x-www-form-urlencoded et multipart/form-data dans $_POST et $_FILES, mais seulement pour les requêtes POST. Les requêtes PATCH et PUT avec les mêmes types de contenu nécessitaient un parsing manuel avec file_get_contents('php://input') et du code personnalisé.

// Dans un handler PATCH
[$_POST, $_FILES] = request_parse_body();

La fonction retourne un tuple. Même logique de parsing que PHP utilise pour POST, maintenant disponible pour n’importe quelle méthode HTTP.

Une nouvelle API DOM qui suit la spec

L’API DOMDocument existante était construite sur une spec DOM level 3 plus ancienne avec des spécificités PHP superposées. 8.4 ajoute un namespace Dom\ parallèle qui implémente le WHATWG Living Standard :

$doc = Dom\HTMLDocument::createFromString('<p class="lead">Hello</p>');
$p = $doc->querySelector('p');
echo $p->classList;  // "lead"
echo $p->id;         // ""

$doc2 = Dom\HTMLDocument::createFromFile('page.html');

Dom\HTMLDocument parse correctement HTML5, tag soup inclus. Dom\XMLDocument gère le XML strict. Les nouvelles classes sont strictes sur les types, retournent les bons types de nœuds, et exposent des propriétés modernes comme classList, id, className. L’ancien DOMDocument reste, inchangé, pour la compatibilité ascendante.

PDO reçoit des sous-classes spécifiques au driver

PDO::connect() et l’instanciation directe retournent maintenant des sous-classes spécifiques au driver quand elles sont disponibles :

$pdo = PDO::connect('mysql:host=localhost;dbname=test', 'user', 'pass');
// $pdo est maintenant une instance Pdo\Mysql

$pdo = new Pdo\Pgsql('pgsql:host=localhost;dbname=test', 'user', 'pass');

Chaque sous-classe driver (Pdo\Mysql, Pdo\Pgsql, Pdo\Sqlite, Pdo\Firebird, Pdo\Odbc, Pdo\DbLib) peut exposer des méthodes spécifiques au driver sans polluer l’interface PDO de base. Doctrine, Laravel et autres ORMs similaires peuvent maintenant type-hinter contre la classe de driver spécifique quand ils ont besoin d’un comportement spécifique au driver.

OpenSSL reçoit le support des clés modernes

openssl_pkey_new() et les fonctions associées supportent maintenant Curve25519 et Curve448, les courbes elliptiques modernes qui ont remplacé les anciennes courbes NIST dans la plupart des recommandations de sécurité :

$key = openssl_pkey_new(['curve_name' => 'ed25519', 'private_key_type' => OPENSSL_KEYTYPE_EC]);
$details = openssl_pkey_get_details($key);

x25519 et x448 pour l’échange de clés, ed25519 et ed448 pour les signatures. Les quatre fonctionnent maintenant avec openssl_sign() et openssl_verify().

PCRE : lookbehind de longueur variable

La mise à jour de la bibliothèque PCRE2 embarquée (10.44) apporte les assertions lookbehind de longueur variable, quelque chose que les moteurs regex de Perl et Python avaient et que PHP ne pouvait pas faire :

// Correspondre "bar" seulement quand précédé de "foo" ou "foooo"
preg_match('/(?<=foo+)bar/', 'foooobar', $matches);

Les assertions lookbehind nécessitaient auparavant un pattern de largeur fixe. Elles peuvent maintenant correspondre à des patterns de longueur variable. Le modificateur r (PCRE2_EXTRA_CASELESS_RESTRICT) est aussi nouveau : il empêche le mélange de caractères ASCII et non-ASCII dans les correspondances insensibles à la casse, fermant une classe d’attaques de confusion Unicode.

DateTime reçoit les microsecondes et une factory de timestamp

$dt = DateTimeImmutable::createFromTimestamp(1700000000.5);
echo $dt->getMicrosecond(); // 500000

$with_micros = $dt->setMicrosecond(123456);

createFromTimestamp() accepte un float pour une précision sous-seconde. getMicrosecond() et setMicrosecond() complètent l’API pour le composant microseconde qui était à l’intérieur de DateTime mais inaccessible directement.

fpow() pour la conformité IEEE 754

pow(0, -2) en PHP retournait historiquement une valeur définie par l’implémentation. 8.4 déprécie pow() avec une base zéro et un exposant négatif et introduit fpow(), qui suit strictement IEEE 754 : fpow(0, -2) retourne INF, comme le standard le définit :

echo fpow(2.0, 3.0);   // 8.0
echo fpow(0.0, -1.0);  // INF
echo fpow(-1.0, INF);  // 1.0

À retenir dans tout code faisant des calculs mathématiques où la conformité IEEE compte.

Le coût de bcrypt augmente

Le coût par défaut pour password_hash() avec PASSWORD_BCRYPT est passé de 10 à 12. Ça impacte tout code appelant password_hash($pass, PASSWORD_BCRYPT) sans coût explicite. L’objectif est de maintenir le défaut grossièrement à “quelques centaines de millisecondes sur du matériel moderne” à mesure que le matériel devient plus rapide.

Si on stocke des hash bcrypt et qu’on monte sur 8.4, les hash existants restent valides : password_verify() lit le coût depuis le hash lui-même. Les nouveaux hash utilisent le coût 12. password_needs_rehash() retourne true pour les anciens hash si on passe ['cost' => 12], donc on peut les mettre à jour à la prochaine connexion.

Les dépréciations qui comptent

Les paramètres implicitement nullable sont dépréciés. Si un paramètre a un défaut de null, le type doit le dire explicitement :

// Déprécié dans 8.4
function foo(string $s = null) {}

// Correct
function foo(?string $s = null) {}
function foo(string|null $s = null) {}

trigger_error() avec E_USER_ERROR est déprécié : le remplacer par une exception ou exit(). Le niveau E_USER_ERROR a toujours été un hybride maladroit entre une erreur récupérable et une erreur fatale, et personne n’était sûr lequel.

lcg_value() est aussi déprécié. Utiliser Random\Randomizer::getFloat() à la place. Le générateur LCG avait de mauvaises propriétés d’aléatoire et aucun contrôle de graine.

Les constantes de classe typées

Les constantes de classe n’ont jamais été typées depuis leur introduction. PHP 8.3 corrige ça :

interface HasVersion {
    const string VERSION;
}

class App implements HasVersion {
    const string VERSION = '1.0.0';
}

Sans constantes typées, une constante d’interface pouvait être redéfinie avec un type complètement différent dans une classe implémentante sans que rien ne se plaigne. Les constantes typées comblent ce trou, et sur les bases de code pilotées par les interfaces, l’impact est immédiat.

L’accès dynamique aux constantes de classe

Une lacune qui nécessitait un contournement depuis que les constantes existent :

$name = 'STATUS';
echo MyClass::{$name}; // ça marche maintenant

Avant, accéder à une constante avec un nom dynamique signifiait appeler constant('MyClass::STATUS'). La nouvelle syntaxe est cohérente avec la façon dont PHP gère déjà les variables variables et les appels de méthodes dynamiques.

readonly peut maintenant être modifié dans clone

Une limitation spécifique mais vraiment agaçante de 8.1 avec readonly : on ne pouvait pas cloner un objet et changer une propriété readonly. 8.3 ajoute la possibilité de réinitialiser les propriétés readonly pendant le clonage, ce qui rend les value objects immuables utilisables dans beaucoup plus de patterns.

json_validate()

if (json_validate($string)) {
    $data = json_decode($string);
}

Avant 8.3, la seule façon de valider une chaîne JSON était de la décoder et de vérifier les erreurs. json_validate() vérifie sans allouer la structure décodée, ce qui compte quand on a juste besoin de savoir si la chaîne est du JSON valide, pas ce qu’elle contient.

Améliorations du Randomizer

getBytesFromString() génère une chaîne aléatoire composée uniquement de caractères d’un ensemble donné :

$rng = new Random\Randomizer();
$token = $rng->getBytesFromString('abcdefghijklmnopqrstuvwxyz0123456789', 32);

L’approche précédente : str_split, array_map, sélection aléatoire, implode. Ça marchait, mais c’était plus long que ça n’avait le droit d’être.

8.3 est pour les équipes qui adoptent les versions PHP rapidement et veulent les améliorations incrémentales. Les constantes typées seules valent le coup sur toute base de code avec des constantes d’interface.

#[\Override] rend l’héritage explicite

Avant 8.3, rien n’empêchait d’écrire une méthode qu’on croyait surcharger celle d’un parent, alors qu’on avait un typo dans le nom ou que le parent l’avait silencieusement supprimée. Des bugs silencieux, zéro retour du moteur.

class Cache {
    #[\Override]
    public function get(string $key): mixed {
        // Le moteur vérifie que cette méthode existe dans un parent ou une interface
    }
}

Si la méthode n’existe dans aucune classe parente ou interface implémentée, PHP lève une erreur. Même concept que @Override en Java ou override en C#, enfin en PHP.

final sur les méthodes de trait

Les traits ont toujours eu des aspérités dans le modèle OOP de PHP. Un problème spécifique : une classe utilisant un trait pouvait surcharger n’importe laquelle de ses méthodes, sapant les garanties que le trait essayait de fournir. 8.3 laisse le trait lui-même marquer une méthode comme final :

trait Singleton {
    final public static function getInstance(): static {
        // ...
    }
}

Maintenant, une classe utilisant le trait ne peut pas surcharger getInstance(). La garantie tient.

Les classes anonymes peuvent être readonly

PHP 8.1 avait apporté les classes readonly. Les classes anonymes avaient été laissées de côté pour une raison obscure. 8.3 corrige ça :

$point = new readonly class(3, 4) {
    public function __construct(
        public float $x,
        public float $y,
    ) {}
};

Pratique quand on a besoin d’un value object immuable jetable sans la cérémonie de lui donner un nom.

Les initialiseurs de variables statiques acceptent des expressions

Une restriction petite mais ancienne : les initialiseurs de variables statiques n’acceptaient que des expressions constantes, pas d’appels de fonctions. 8.3 lève cette contrainte :

function connection(): PDO {
    static $pdo = new PDO(getenv('DATABASE_URL'));
    return $pdo;
}

L’initialiseur s’exécute une seule fois au premier appel, la variable statique persiste. Faisable avec un test null avant, c’est juste plus propre.

mb_str_pad() existe enfin

str_pad() a toujours été conscient des octets, pas des caractères. Pour les chaînes multibyte (arabe, japonais, caractères accentués) il produisait une sortie incorrecte. 8.3 ajoute enfin la variante multibyte :

$padded = mb_str_pad('日本', 10, '*', STR_PAD_BOTH);

La fonction respecte les limites de caractères, pas les comptages d’octets.

str_increment() et str_decrement()

L’opérateur ++ de PHP sur les chaînes a une histoire de bizarreries : il incrémente les séquences de lettres ('a' → 'b', 'z' → 'aa'), mais -- n’a jamais fonctionné symétriquement. Le comportement était suffisamment surprenant que 8.3 déprécie ++/-- sur les chaînes non alphanumériques et introduit des fonctions explicites :

echo str_increment('a');  // b
echo str_increment('Az'); // Ba
echo str_decrement('b');  // a
echo str_decrement('Ba'); // Az

Les fonctions rendent l’intention évidente et le comportement prévisible.

Random\Randomizer gagne le support des flottants

8.3 comble le côté flottant de l’API Randomizer :

$rng = new Random\Randomizer();

// Un flottant dans [0.0, 1.0)
$f = $rng->nextFloat();

// Un flottant dans une plage spécifique avec contrôle de l'inclusion des bornes
$f = $rng->getFloat(1.5, 3.5, Random\IntervalBoundary::ClosedOpen);

IntervalBoundary est un nouvel enum avec quatre valeurs : ClosedOpen, ClosedClosed, OpenClosed, OpenOpen. C’est important pour la justesse statistique : l’approche naïve avec rand() / getrandmax() ne produit pas une distribution uniforme sur les flottants.

La hiérarchie d’exceptions de Date

Les erreurs de date/heure en PHP levaient des exceptions génériques sans moyen de distinguer “chaîne malformée” de “timezone invalide” sans parser le message. 8.3 ajoute une hiérarchie propre :

try {
    new DateTimeImmutable('not a date');
} catch (DateMalformedStringException $e) {
    // spécifiquement un échec de parsing
} catch (DateException $e) {
    // autres erreurs liées aux dates
}

L’arbre complet : DateError (niveau moteur), DateException (base), avec des sous-classes spécifiques pour timezone invalide, chaîne d’intervalle malformée, chaîne de période malformée, et chaîne de date malformée.

gc_status() en dit plus

gc_status() retourne maintenant huit champs supplémentaires : running, protected, full, buffer_size, et des décompositions temporelles (application_time, collector_time, destructor_time, free_time). Si vous profilez la pression mémoire ou les pauses GC, ces données étaient auparavant inaccessibles sans passer par une extension.

strrchr() gagne un argument de direction

strrchr() (trouver la dernière occurrence d’un caractère, retourner de là jusqu’à la fin) accepte maintenant un booléen $before_needle, alignant son API sur celle de strstr() :

$path = '/var/www/html/index.php';
echo strrchr($path, '/', before_needle: true);  // /var/www/html
echo strrchr($path, '/');                        // /index.php

Une fonction présente dans PHP depuis 1994, enfin cohérente avec sa voisine.

Dépréciations à noter

get_class() et get_parent_class() sans arguments émettent maintenant des avertissements de dépréciation. Les formes sans argument reposaient sur un contexte $this implicite, facile à mal lire. Passez l’objet explicitement.

assert_options() et les constantes ASSERT_* sont dépréciées au profit de la directive INI zend.assertions, qui est le bon outil pour contrôler le comportement des assertions selon les environnements.

Les opérateurs ++/-- sur les chaînes vides et les chaînes non numériques non alphanumériques émettent maintenant des avertissements de dépréciation. Le comportement était un territoire indéfini. 8.3 amorce la migration vers un comportement défini en 9.0.

Protection contre les débordements de pile

Deux nouvelles directives INI : zend.max_allowed_stack_size fixe une limite dure sur la profondeur de pile de PHP, et zend.reserved_stack_size réserve un buffer pour le nettoyage après qu’une limite soit atteinte. Avant 8.3, un code récursif profond pouvait tout simplement crasher au niveau OS. Maintenant PHP l’intercepte et lève une Error avec un message utile.

Les propriétés dynamiques dépréciées

PHP a toujours permis d’ajouter des propriétés à des objets sans les déclarer dans la classe :

class User {}
$user = new User();
$user->name = 'Alice'; // aucune déclaration, aucune erreur... jusqu'ici

En 8.2, ça déclenche un avertissement de dépréciation. En PHP 9.0, ce sera une erreur fatale. Le délai de grâce existe, mais le compteur tourne.

La logique est solide : les propriétés dynamiques sont une source classique de typos qui passent silencieusement (écrivez $user->nmae et PHP crée simplement une nouvelle propriété au lieu de se plaindre). Des déclarations explicites rendent le contrat de la classe lisible et donnent aux outils matière à travailler.

La migration est essentiellement mécanique : déclarez les propriétés, ou posez #[AllowDynamicProperties] sur les classes legacy que vous ne pouvez pas encore toucher.

Les classes readonly

8.1 avait ajouté readonly sur les propriétés individuelles. 8.2 l’ajoute sur la déclaration de classe elle-même :

readonly class Point {
    public function __construct(
        public float $x,
        public float $y,
        public float $z,
    ) {}
}

Toutes les propriétés promues et déclarées explicitement deviennent readonly automatiquement. Les value objects (coordonnées, montants monétaires, identifiants) sont la cible évidente. La syntaxe est propre et l’intention se lit clairement.

Une contrainte : les classes readonly ne peuvent pas avoir de propriétés non typées, ce qui était déjà une mauvaise idée avec readonly de toute façon.

Les types DNF

Les types en Forme Normale Disjonctive permettent de combiner types union et types intersection :

function process(Countable&Iterator|null $collection): void { ... }

(Countable&Iterator)|null : un objet qui implémente les deux interfaces, ou null. Cela couvre des expressions de type que les unions de 8.0 et les intersections de 8.1 approchaient chacune sans pouvoir les représenter ensemble.

L’extension Random

Une extension Random dédiée remplace les fonctions éparpillées rand(), mt_rand(), random_int() par une API orientée objet :

$rng = new Random\Randomizer();
$rng->getInt(1, 100);
$rng->shuffleArray($items);

Les moteurs sont interchangeables : Mersenne Twister, PCG64, Xoshiro256StarStar, ou CryptoSafeEngine pour les contextes sensibles à la sécurité. Même code, moteur déterministe avec seed dans les tests, moteur cryptographique en production.

8.2 est une version de consolidation. La dépréciation des propriétés dynamiques est la seule décision à prendre maintenant.

null, false, et true comme types autonomes

PHP avait les types nullable depuis 7.1 et les types union depuis 8.0, mais null comme déclaration de type autonome n’était pas valide. 8.2 corrige ça :

function alwaysNull(): null {
    return null;
}

function disabled(): false {
    return false;
}

function enabled(): true {
    return true;
}

false et true comme types autonomes sont utiles quand on veut être précis sur ce qu’une fonction peut réellement retourner. C’est étroit mais juste : une fonction qui retourne false en cas d’échec et une chaîne en cas de succès devrait déclarer string|false, et maintenant les deux côtés de cette union sont de vrais types.

Les constantes dans les traits

Les traits pouvaient contenir des propriétés et des méthodes. Les constantes étaient le trou dans la raquette. 8.2 le comble :

trait Timestamps {
    public const DATE_FORMAT = 'Y-m-d H:i:s';

    public function formatCreatedAt(): string {
        return $this->createdAt->format(self::DATE_FORMAT);
    }
}

class Article {
    use Timestamps;
}

echo Article::DATE_FORMAT; // 'Y-m-d H:i:s'

La constante appartient à la classe qui utilise le trait, pas au trait lui-même, donc on ne peut pas accéder à Timestamps::DATE_FORMAT directement. Comportement de scope attendu, cohérent avec le fonctionnement des méthodes de trait.

#[SensitiveParameter]

Les stack traces ont toujours été un risque : les arguments de fonction sont loggés verbatim, ce qui veut dire que les mots de passe et les tokens se retrouvent dans les logs d’erreur et les dashboards de monitoring. 8.2 ajoute un attribut pour stopper ça :

function authenticate(
    string $user,
    #[\SensitiveParameter] string $password,
): bool {
    // si ça lève une exception, la stack trace affiche :
    // authenticate('alice', Object(SensitiveParameterValue))
    return hash('sha256', $password) === getStoredHash($user);
}

La valeur du paramètre dans la trace est remplacée par un objet SensitiveParameterValue. Un attribut, zéro excuse pour ne pas l’ajouter sur chaque fonction qui touche à des credentials.

Les syntaxes d’interpolation de chaînes dépréciées

Deux façons d’interpoler des expressions dans des chaînes sont dépréciées en 8.2 :

$name = 'world';

// Celles-ci sont dépréciées :
echo "Hello ${name}";       // utiliser "$name" ou "{$name}"
echo "Hello ${getName()}";  // utiliser "{$this->getName()}"

Les formes ${...} créaient une ambiguïté entre les variables variables et les expressions. La syntaxe plus propre {$...} a toujours été là et fait la même chose. C’est essentiellement un travail de recherche-remplacement sur les bases de code qui ont adopté les formes dépréciées par habitude.

utf8_encode() et utf8_decode() dépréciées

Ces deux fonctions sont dépréciées en 8.2 et disparaissent en 9.0. Leur comportement a toujours été plus étroit que ce que les noms suggéraient : utf8_encode() convertit ISO-8859-1 en UTF-8, pas “n’importe quel encodage en UTF-8”.

// Déprécié en 8.2 :
$utf8 = utf8_encode($latin1String);

// Utiliser à la place :
$utf8 = mb_convert_encoding($latin1String, 'UTF-8', 'ISO-8859-1');

mb_convert_encoding() ou iconv() gèrent le cas général. Si vous traitez vraiment des entrées en Latin-1, le remplacement est direct.

Les fonctions de chaîne indépendantes de la locale

Plusieurs fonctions de chaîne variaient silencieusement leur comportement selon la locale système, produisant des résultats différents en production par rapport à un container de dev. En 8.2, elles sont indépendantes de la locale et ne gèrent que l’ASCII :

// strtolower, strtoupper, stristr, stripos, strripos,
// lcfirst, ucfirst, ucwords, str_ireplace font maintenant une conversion
// de casse ASCII uniquement.
// Pour un comportement sensible à la locale, utiliser les équivalents mb_* :
$lowered = mb_strtolower($text, 'UTF-8');

C’est un correctif de cohérence. Si votre code reposait sur le comportement sensible à la locale de ces fonctions, il était déjà cassé sur des systèmes avec des configurations de locale différentes. 8.2 rend le comportement déterministe partout, ce qui est ce qu’on voulait vraiment.

str_split() sur une chaîne vide

Un changement de comportement discret à noter :

// PHP 8.1 : str_split('') === ['']
// PHP 8.2 : str_split('') === []

Le nouveau comportement a plus de sens : découper rien ne produit rien. Si vous vérifiez count(str_split($input)), une entrée vide ne produit plus un count de 1.

Les enums

C’est la nouveauté qui change les bases de code dès la mise à jour. Avant 8.1, les énumérations en PHP se résumaient à des constantes de classe, des chaînes ou des entiers sans rien pour les faire respecter :

// avant : rien n'empêche de passer Status::INVALID
const ACTIVE = 'active';
const INACTIVE = 'inactive';

// après
enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
}

function activate(Status $status): void { ... }

Les enums PHP sont des objets, pas des scalaires. Ils supportent les méthodes, les interfaces et les constantes. Les backed enums (avec une valeur string ou int) se sérialisent proprement et se mappent naturellement aux colonnes de base de données. Les pure enums (sans type de backing) expriment des concepts métier sans se soucier de la sérialisation.

L’effet immédiat : chaque champ de statut, chaque ensemble fini d’états dans toutes les bases de code que je maintiens est devenu un candidat à l’enum. Le système de types a enfin un moyen natif d’exprimer ce que chaque projet PHP simulait depuis des années.

Les fibers

Les fibers sont une primitive de concurrence coopérative : vous pouvez suspendre et reprendre l’exécution d’une fonction, en cédant le contrôle sans recourir aux threads.

$fiber = new Fiber(function(): void {
    $value = Fiber::suspend('first');
    echo "Repris avec : {$value}\n";
});

$result = $fiber->start();    // 'first'
$fiber->resume('hello');      // "Repris avec : hello"

Les fibers sont la fondation dont les bibliothèques async comme ReactPHP et Amp avaient besoin depuis un moment du côté du runtime. Pour la plupart des développeurs d’applications, l’API directe compte moins que les bibliothèques construites par-dessus, mais comprendre les fibers explique ce que font ces bibliothèques en coulisses.

:pencil2: Les propriétés readonly

8.0 avait apporté la promotion des paramètres du constructeur. 8.1 ajoute readonly :

class User {
    public function __construct(
        public readonly int $id,
        public readonly string $name,
    ) {}
}

Une propriété readonly ne peut être écrite qu’une seule fois, lors de l’initialisation. Après ça, toute écriture lève une Error. Combiné avec la promotion des paramètres, les value objects et les DTOs deviennent concis et signifient réellement ce qu’ils annoncent.

La syntaxe callable de première classe

$fn = strlen(...);
$fn = $this->process(...);
$fn = MyClass::create(...);

... après un callable crée une Closure sans le boilerplate de Closure::fromCallable(). Utile quand on passe des méthodes comme callbacks.

8.1 est précis. Les enums justifient à eux seuls la mise à jour.

Les types d’intersection

Les types union ont débarqué en 8.0. Les types d’intersection suivent en 8.1. Là où un union dit « l’un ou l’autre », une intersection dit « tous à la fois » :

function process(Countable&Iterator $collection): void {
    foreach ($collection as $item) { /* ... */ }
    echo count($collection);
}

Une contrainte : les types d’intersection ne peuvent pas être mélangés avec les types union dans la même déclaration (ça arrivera en 8.2 avec les DNF types). Mais ça débloque déjà une vérification de types précise pour les objets qui doivent satisfaire plusieurs interfaces à la fois, un pattern que les frameworks utilisent constamment et qui devait rester sans typage jusqu’ici.

Le type de retour never

Une fonction qui ne retourne jamais (elle lève toujours une exception ou sort) a maintenant un type pour le dire :

function redirect(string $url): never {
    header("Location: {$url}");
    exit();
}

function fail(string $message): never {
    throw new \RuntimeException($message);
}

L’avantage concret : les analyseurs statiques peuvent prouver que le code après une fonction never est inatteignable, et les appelants savent qu’il n’y a pas de valeur de retour à gérer. Avant ça, ça vivait dans des docblocks sans enforcement.

Les constantes de classe finales

Avant 8.1, n’importe quelle sous-classe pouvait silencieusement surcharger la constante de classe d’un parent. Maintenant vous pouvez y mettre un terme :

class Base {
    final public const VERSION = '1.0';
}

class Child extends Base {
    // Fatal error: Cannot override final constant Base::VERSION
    public const VERSION = '2.0';
}

Parallèlement, les constantes d’interface sont désormais surchargeables par les classes implémentant l’interface par défaut. Un correctif de comportement qui était incohérent depuis l’introduction des interfaces.

new dans les initialiseurs

Les valeurs par défaut des paramètres étaient autrefois limitées aux scalaires et aux tableaux. 8.1 lève cette restriction :

class Logger {
    public function __construct(
        private Handler $handler = new NullHandler(),
    ) {}
}

function createUser(
    Validator $validator = new DefaultValidator(),
): User { /* ... */ }

Idem pour les arguments d’attributs et les initialiseurs de variables statiques. Ce qui signifie que l’injection de dépendances avec des valeurs par défaut sensées ne nécessite plus une vérification de null et une instanciation paresseuse dans le corps de la méthode.

Le déballage de tableaux avec des clés string

Le déballage de tableau via l’opérateur spread ne fonctionnait qu’avec des tableaux à clés entières avant 8.1. Les clés string fonctionnent aussi maintenant :

$defaults = ['color' => 'red', 'size' => 'M'];
$custom = ['size' => 'L', 'weight' => '200g'];

$merged = [...$defaults, ...$custom];
// ['color' => 'red', 'size' => 'L', 'weight' => '200g']

Les clés ultérieures écrasent les précédentes. Même comportement que array_merge(), mais exprimé inline. La différence de performance est marginale ; la différence de lisibilité, elle, ne l’est pas.

fsync et fdatasync

Deux fonctions qui n’avaient aucune bonne raison d’être absentes d’un langage orienté système de fichiers :

$fp = fopen('/tmp/important.dat', 'w');
fwrite($fp, $data);
fsync($fp);   // vide les buffers OS vers le stockage physique
fclose($fp);

fdatasync() fait la même chose mais saute la synchronisation des métadonnées quand on ne se soucie que de la durabilité des données. Les deux retournent false en cas d’échec. Si vous écrivez quoi que ce soit qui nécessite une sécurité en cas de crash, vous aviez besoin de ça.

Passer null aux paramètres non-nullables des fonctions internes

Un changement plus discret mais aux conséquences réelles : les fonctions internes qui acceptent des chaînes, des entiers, etc. ont toujours avalé silencieusement null et l’ont coercé. En 8.1, ça commence à émettre un avertissement de dépréciation.

str_contains("foobar", null);
// Deprecated: Passing null to parameter #2 ($needle) of type string is deprecated

Ça aligne les fonctions internes sur les fonctions définies par l’utilisateur, qui refusaient déjà les arguments nullable pour des paramètres non-nullables. PHP 9.0 transforme ça en erreur fatale. Si vous passez null dans des fonctions de chaînes, c’est maintenant un meilleur moment pour le corriger que pendant un incident de production.

MySQLi lève des exceptions par défaut

Avant 8.1, MySQLi échouait silencieusement sauf si vous appeliez explicitement mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT). C’est maintenant la valeur par défaut :

// Ceci lève \mysqli_sql_exception en cas d'échec de connexion en 8.1
// Auparavant retournait false et définissait une erreur que vous deviez vérifier manuellement
$connection = new mysqli('localhost', 'user', 'wrong_password', 'db');

Toute base de code qui attrape les erreurs MySQLi en vérifiant les valeurs de retour doit être revue. Les échecs silencieux qui causaient des bugs difficiles à diagnostiquer lèvent maintenant des exceptions, ce qui est le bon comportement, même si ça peut surprendre si vous l’attrapez en pleine mise à jour.

JIT

Le compilateur Just-In-Time était l’annonce principale. La réalité en production est plus nuancée : pour les applications web typiques (requêtes en base, appels HTTP, rendu de templates) les gains sont modestes, parce que ces workloads sont limités par les I/O, pas par le calcul. Là où le JIT brille vraiment, c’est le code intensif en CPU : manipulation d’images, transformation de données, calcul mathématique.

Pour la plupart des applications web, l’amélioration de performance vient du travail sur le moteur en général dans 8.0, pas du JIT spécifiquement. Vaut quand même la peine de l’activer : ça ne coûte rien sur les workloads I/O-bound.

Les expressions match

switch a trois problèmes : il utilise la comparaison souple, il tombe en cascade par défaut, et il ne peut pas être utilisé comme expression. match règle les trois :

$result = match($status) {
    'active', 'pending' => 'processing',
    'done'             => 'finished',
    default            => throw new \UnexpectedValueException($status),
};

Comparaison stricte. Pas de cascade. Expression qui retourne une valeur. Un match non exhaustif lève une exception. Après une semaine avec match, j’ai arrêté d’écrire des switch.

Les arguments nommés

array_slice(array: $users, offset: 0, length: 10, preserve_keys: true);

Les arguments nommés permettent de passer les arguments dans n’importe quel ordre et d’en sauter des optionnels. Le gain évident : la lisibilité sur les fonctions avec plusieurs flags booléens. Le gain moins évident : les arguments nommés survivent aux mises à jour de PHP même quand l’ordre des paramètres change, parce qu’on nomme ce qu’on veut dire.

Les attributs

Place aux docblock annotations (le style @Route, @ORM\Column sur lequel les frameworks se sont appuyés pendant des années), bienvenue à la syntaxe PHP de première classe :

#[Route('/users', methods: ['GET'])]
#[IsGranted('ROLE_ADMIN')]
public function list(): Response { ... }

Les attributs sont validés par le moteur, pas parsés depuis des strings. Le support IDE fonctionne directement, sans magie de plugin. Pour les utilisateurs de Symfony et Doctrine, c’est le vrai gain quotidien de PHP 8.0.

La promotion de constructeur

class User {
    public function __construct(
        public readonly int $id,
        public string $name,
        private ?string $email = null,
    ) {}
}

Propriétés déclarées et assignées en une ligne dans la signature du constructeur. Le gain de refactoring le plus immédiat dans 8.0 : chaque classe de données que j’ai touchée depuis la mise à jour fait moitié moins de lignes qu’avant.

L’opérateur nullsafe

$city = $user?->getAddress()?->getCity()?->getName();

null à n’importe quel point de la chaîne court-circuite le reste et retourne null. L’alternative était des null checks imbriqués ou une chaîne de retours anticipés. Ça se compose naturellement.

Les types union

Les arguments nommés rendent les signatures de fonctions plus explicites au site d’appel. Les types union les rendent plus honnêtes au site de déclaration :

function processInput(int|float|string $value): string|int
{
    if (is_string($value)) {
        return strlen($value);
    }
    return (int) round($value);
}

L’union int|float|string est un OU littéral. Le moteur l’impose à l’entrée et à la sortie. Avant 8.0, “ce paramètre accepte int ou float” vivait dans un docblock que rien n’imposait. Il y a aussi null comme composant de type : ?string est juste du sucre syntaxique pour string|null, les deux sont valides.

Un cas spécial : false. PHP a un tas de fonctions natives qui retournent une valeur typée en cas de succès et false en cas d’échec. Le système de types de 8.0 accommode ça : array|false, string|false. C’est une reconnaissance honnête que la codebase ne peut pas être réécrite du jour au lendemain.

Le type de retour static

static comme type de retour était possible de manière informelle via les docblocks, mais 8.0 le rend officiel. La distinction entre self et static compte dans l’héritage :

class Builder {
    protected array $config = [];

    public function set(string $key, mixed $value): static {
        $this->config[$key] = $value;
        return $this;
    }
}

class SpecialBuilder extends Builder {}

$result = (new SpecialBuilder())->set('foo', 'bar');
// $result est SpecialBuilder, pas Builder

Avec self comme type de retour, cette chaîne retournerait Builder, cassant les interfaces fluides dans les sous-classes. static fait fonctionner correctement les APIs fluides à travers les hiérarchies d’héritage sans surcharges manuelles.

Le type mixed

mixed était une convention de docblock pendant des années. 8.0 en fait un vrai type qui apparaît dans les signatures :

function debug(mixed $value): void {
    var_dump($value);
}

Il accepte tout : null, objets, ressources, scalaires, tableaux. Sémantiquement c’est la même chose que n’avoir aucune déclaration de type, mais c’est explicite plutôt qu’absent. La différence entre “ce paramètre est non typé” et “ce paramètre accepte intentionnellement n’importe quoi.” Vaut la peine de l’utiliser quand on écrit un utilitaire généraliste qui serait malhonnête avec un type plus étroit.

throw comme expression

Avant 8.0, throw était une instruction. Ça semble une distinction pédante jusqu’à ce qu’on tombe sur les endroits où on veut vraiment une expression :

// Dans un ternaire :
$value = $input ?? throw new \InvalidArgumentException('input required');

// Dans une arrow function :
$getId = fn(User $u) => $u->id ?? throw new \RuntimeException('no id');

// Dans un bras match (qui est déjà une expression) :
$status = match($code) {
    200     => 'ok',
    404     => 'not found',
    default => throw new \UnexpectedValueException("unknown code: $code"),
};

Le dernier est particulièrement utile : un match sans default lancera UnhandledMatchError automatiquement, mais parfois on veut contrôler le type d’exception et le message.

catch sans variable

Petite amélioration de qualité de vie. Quand on attrape une exception mais qu’on n’utilise pas réellement l’objet, 8.0 permet d’omettre la variable :

try {
    $result = $cache->get($key);
} catch (CacheMissException) {
    $result = $this->compute($key);
}

Avant 8.0, il fallait écrire catch (CacheMissException $e) et ensuite soit utiliser $e soit vivre avec l’avertissement IDE sur la variable inutilisée. Aucune des deux options n’était satisfaisante.

Les fonctions string qui auraient dû exister depuis des années

Trois fonctions que chaque développeur PHP a écrites manuellement au moins une fois :

str_contains('hello world', 'world');  // true
str_starts_with('hello world', 'hell'); // true
str_ends_with('hello world', 'world'); // true

Avant 8.0, les approches habituelles étaient strpos() !== false, strncmp(), ou substr() ===, qui nécessitent toutes de s’arrêter pour se souvenir de la sémantique. Ces nouvelles fonctions sont juste directes et lisibles. Pas de regex, pas d’arithmétique d’offset.

Un tri stable

Les fonctions de tri de PHP n’étaient pas stables avant 8.0. “Pas stable” signifie que les éléments qui se comparent comme égaux pouvaient se retrouver dans n’importe quel ordre les uns par rapport aux autres. En pratique, ça causait des bugs subtils dans le code UI qui avait besoin d’un ordre cohérent, une pagination qui changeait entre les chargements, et des tests qui ne passaient que par chance.

8.0 garantit la stabilité à travers toutes les fonctions de tri : sort(), usort(), array_multisort(), et le reste. Les éléments égaux conservent leur position relative originale. C’est le comportement que la plupart des gens supposaient déjà être là.

WeakMap

7.4 apportait WeakReference pour les objets simples. 8.0 apporte WeakMap : une map où les clés (des objets) et leurs données associées peuvent être ramassées par le GC quand aucune autre référence à l’objet-clé n’existe :

class RequestCache {
    private WeakMap $cache;

    public function __construct() {
        $this->cache = new WeakMap();
    }

    public function get(Request $request): Response {
        return $this->cache[$request] ??= $this->compute($request);
    }
}

Dès que $request n’est plus référencé ailleurs, l’entrée disparaît de la map. Pas de nettoyage manuel nécessaire. C’est le bon pattern pour la mémoïsation et les caches de propriétés calculées où on ne veut pas être la seule raison qu’un objet reste vivant.

Les nouveaux types d’exception

ValueError est levée quand une fonction reçoit le bon type mais une valeur invalide, par opposition à TypeError qui se déclenche sur les mauvais types :

array_chunk([], -5); // ValueError: array_chunk(): Argument #2 ($length) must be greater than 0

Avant 8.0, beaucoup de ces cas étaient des warnings qui retournaient false ou null. Maintenant ils lèvent des exceptions. Le moteur est plus strict, ce qui signifie qu’on attrape les problèmes plus tôt plutôt que d’obtenir des résultats bizarres quelque part en aval.

get_debug_type() et fdiv()

Deux fonctions utilitaires à connaître.

get_debug_type() retourne une représentation string normalisée de n’importe quelle valeur, pratique pour les messages d’erreur :

get_debug_type(1);          // "int"
get_debug_type(1.0);        // "float"
get_debug_type(null);       // "null"
get_debug_type(new Foo());  // "Foo" (pas "object")
get_debug_type([]);         // "array"

La différence avec gettype() : elle retourne les noms de classes pour les objets et utilise des noms normalisés ("int" pas "integer"). Exactement ce qu’on veut pour construire un message d’exception qui dit ce qu’on a reçu versus ce qu’on attendait.

fdiv() effectue une division en virgule flottante suivant IEEE 754, ce qui signifie que la division par zéro retourne INF, -INF, ou NAN au lieu d’un warning :

fdiv(10, 0);   // INF
fdiv(-10, 0);  // -INF
fdiv(0, 0);    // NAN

Les changements qui cassent des choses

8.0 inclut aussi quelques changements qui ne sont pas des fonctionnalités, ce sont des corrections.

Le plus important : 0 == "foo" est maintenant false. En PHP 7, comparer un entier à une string non numérique castait la string en 0, donc 0 == "n'importe-quoi-non-numérique" s’évaluait à true. C’était une source persistante de bugs et de maux de tête de sécurité. PHP 8 l’inverse : l’entier est casté en string à la place :

var_dump(0 == "foo");  // bool(false) en 8.0, bool(true) en 7.x
var_dump(0 == "");     // bool(false) en 8.0, bool(true) en 7.x
var_dump(0 == "0");    // bool(true) dans les deux ("0" est numérique)

Si on s’appuyait sur ça intentionnellement, on savait déjà que c’était douteux. Si on ne savait pas qu’on s’en appuyait, 8.0 va trouver ces chemins de code.

Plusieurs fonctions qui retournaient des ressources retournent maintenant des objets propres : curl_init() retourne un CurlHandle, imagecreate() retourne un GdImage, xml_parser_create() retourne un XMLParser. Le code qui vérifie is_resource($curl) va casser, parce que is_resource() retourne false pour ces objets. La correction consiste à vérifier contre false (la valeur de retour en cas d’échec) plutôt que de vérifier le type du cas de succès.

PHP 8.0 est le genre de version où les fonctionnalités se renforcent mutuellement. Les attributs se marient bien avec la promotion de constructeur. Match s’associe naturellement avec les types union. Les fonctions string réduisent le bruit qui cachait l’intention. Les corrections sont parfois cassantes, mais elles poussent le langage vers une cohérence qu’il aurait dû avoir depuis des années.

Les propriétés typées

C’est la grande nouveauté. Depuis PHP 7.0, on pouvait typer les paramètres de fonctions et les valeurs de retour. Mais les propriétés de classe ? Toujours non typées :

class User {
    public int $id;
    public string $name;
    public ?DateTimeInterface $deletedAt;
}

7.4 change ça. Les propriétés typées font respecter les types à l’affectation, pas seulement au niveau des sites d’appel. Les classes deviennent auto-documentées d’une façon que les docblocks n’ont jamais vraiment réussi à faire, et le moteur attrape les erreurs de type avant qu’elles ne se propagent dans la moitié de la stack.

Une subtilité : les propriétés typées sont uninitialized par défaut (pas null). Accéder à une propriété non initialisée lève une Error. C’est un piège classique : ?string n’implique pas un défaut de null. Il faut encore un = null explicite pour ça.

Les arrow functions

Les closures en PHP ont toujours nécessité d’importer explicitement les variables de la portée extérieure avec use :

$multiplier = 3;
$fn = fn($x) => $x * $multiplier; // pas besoin de use()

Les arrow functions capturent automatiquement la portée englobante. Expression unique, retour implicite, pas de boilerplate. Elles ne remplacent pas les closures complètes pour la logique complexe, mais pour les callbacks courts, elles éliminent une catégorie de bruit qui s’accumulait depuis des années.

Le préchargement opcache

Pour les setups PHP-FPM à longue durée de vie, le préchargement permet à un script de charger et compiler des fichiers PHP en mémoire opcache au démarrage du serveur. Ces fichiers sont disponibles pour toutes les requêtes sans overhead de compilation.

Le gain varie selon l’application. Sur les grands frameworks où les mêmes fichiers sont chargés à chaque requête, c’est réel. Sur les petites applications, négligeable. Vaut la peine de benchmarker avant d’ajouter la complexité de configuration.

Les petites choses qui s’accumulent

Les fonctionnalités mentionnées en passant méritent plus qu’une ligne. L’opérateur d’affectation null-coalescente ??= résout un pattern suffisamment agaçant à écrire à chaque fois, mais jamais assez pour se donner la peine de l’abstraire :

$config['timeout'] ??= 30;
// équivalent à : $config['timeout'] = $config['timeout'] ?? 30;

L’opérateur spread dans les littéraux de tableau fait ce qu’on attend de la version pour les appels de fonctions — dépacker un itérable dans un littéral de tableau :

$defaults = ['color' => 'blue', 'size' => 'M'];
$options = ['size' => 'L', ...$defaults, 'weight' => 1.2];
// ['size' => 'M', 'color' => 'blue', 'weight' => 1.2]

Note : les clés string n’étaient pas supportées dans 7.4 pour le dépaquet de tableau. Ça viendra plus tard.

Les types de retour covariants et les types de paramètres contravariants comblent un vide qui rendait certains patterns d’héritage inutilement maladroits. Une classe enfant peut maintenant affiner son type de retour vers un sous-type de celui du parent, sans erreur fatale :

class Producer {
    public function get(): Iterator {}
}
class ChildProducer extends Producer {
    public function get(): ArrayIterator {} // ArrayIterator implémente Iterator
}

Lire des nombres à 3h du matin

Le séparateur de littéraux numériques est une de ces fonctionnalités dont on ne sait pas qu’on la voulait jusqu’à la première fois qu’on écrit une grande constante et qu’on perd immédiatement le sens de l’ordre de grandeur :

$earthMass    = 5_972_168_000_000_000_000_000_000; // kg
$lightSpeed   = 299_792_458;                        // m/s
$planck       = 6.626_070_15e-34;                  // J·s
$hexMask      = 0xFF_EC_D5_08;
$binaryFlags  = 0b0001_1111_0010_0000;

L’underscore est purement syntaxique. Le moteur le supprime avant de parser la valeur. On peut le mettre n’importe où entre les chiffres, bien que la convention suive le groupement naturel du système numérique utilisé.

Référencer sans posséder

WeakReference permet de tenir une référence à un objet sans empêcher le ramasse-miettes de le détruire. Le cas d’usage : les caches et registres — on veut savoir qu’un objet est vivant, mais on ne veut pas être la raison qu’il reste vivant :

$object = new HeavyObject();
$ref = WeakReference::create($object);

var_dump($ref->get()); // object(HeavyObject)

unset($object);

var_dump($ref->get()); // NULL — le GC l'a collecté

Avant 7.4, il y avait WeakRef via une extension, et certains frameworks faisaient des tours de passe-passe avec SplObjectStorage qui ne se comportaient pas tout à fait pareil. La classe native est juste directe.

La sérialisation sans surprise

La sérialisation personnalisée d’objets avant 7.4 passait par l’interface Serializable : implémenter serialize() et unserialize(), retourner une string, reconstruire depuis elle. Le problème est que serialize() déclenchait __sleep(), unserialize() déclenchait __wakeup(), et l’interaction entre ces hooks était fragile, surtout dans les hiérarchies d’héritage.

7.4 introduit __serialize() et __unserialize(), qui travaillent avec des tableaux plutôt que des strings et n’interagissent pas avec les anciens hooks :

class Session {
    private string $token;
    private \DateTime $createdAt;

    public function __serialize(): array {
        return ['token' => $this->token, 'created' => $this->createdAt->getTimestamp()];
    }

    public function __unserialize(array $data): void {
        $this->token = $data['token'];
        $this->createdAt = (new \DateTime())->setTimestamp($data['created']);
    }
}

Quand les nouvelles et anciennes méthodes coexistent sur la même classe, __serialize() gagne. L’ancienne interface Serializable est dépréciée dans 8.1.

Ce que la bibliothèque standard a discrètement reçu

mb_str_split() fait ce que str_split() fait mais correctement pour les strings multibyte. Le manque était franchement embarrassant pour un langage utilisé dans autant de locales que PHP :

mb_str_split('héllo', 1); // ['h', 'é', 'l', 'l', 'o']
str_split('héllo', 1);    // ['h', 'Ã', '©', 'l', 'l', 'o'] — cassé

strip_tags() accepte maintenant un tableau de tags autorisés, ce qui est plus propre que le format string qu’il fallait passer auparavant :

strip_tags($html, ['p', 'br', 'strong']); // était : '<p><br><strong>'

proc_open() accepte maintenant un tableau de commandes, contournant complètement l’interprétation par le shell. Même idée que subprocess de Python avec shell=False. À retenir quand on passe des arguments fournis par l’utilisateur à un processus externe.

Le chapitre FFI

L’extension Foreign Function Interface a atterri dans 7.4 après avoir passé du temps dans une branche feature. Elle permet à PHP d’appeler des fonctions C natives en chargeant une bibliothèque partagée et en déclarant les signatures :

$ffi = FFI::cdef("int strlen(const char *s);", "libc.so.6");
var_dump($ffi->strlen("hello")); // int(5)

Les applications pratiques sont étroites mais réelles : appeler des API de plateforme sans binding PHP, wrapper du code C critique pour les performances sans écrire une extension complète, ou juste jouer avec des bibliothèques natives directement. Ce n’est pas un remplacement des extensions propres en production, mais ça supprime la barrière “écrire une extension C” pour l’exploration.

Ce qui a été déprécié

Quelques choses qui auraient dû être nettoyées depuis longtemps ont finalement reçu le traitement dépréciation dans 7.4.

Les ternaires imbriqués sans parenthèses ont toujours été ambigus. PHP les évaluait de gauche à droite alors que pratiquement tous les autres langages avec un ternaire évaluent de droite à gauche :

// Était ambigu, maintenant déprécié :
$a ? $b : $c ? $d : $e;

// Rendre explicite :
($a ? $b : $c) ? $d : $e;

L’accès par offset avec accolades pour les strings et tableaux — $str{0} au lieu de $str[0] — est déprécié et supprimé dans 8.0. C’était toujours un alias, jamais une fonctionnalité distincte.

implode() avec l’ordre d’arguments inversé (tableau en premier, colle en second) est déprécié. La fonction a accepté les deux ordres depuis le début, ce qui était une erreur. L’ordre correct est implode(string $separator, array $array).

Ce qui arrive ensuite

7.4 est la dernière version 7.x. Les dépréciations sont principalement du déblayage pour les suppressions dans 8.0. Le backlog de RFCs pour 8.0 est substantiel : JIT, attributs, arguments nommés, expressions match. 7.4 est un bon endroit où atterrir en attendant que tout ça arrive.

Les types nullables

La 7.0 permettait de déclarer string $name comme type de paramètre. Ce qu’elle ne permettait pas, c’était de dire “ça peut aussi être null”. On devait soit abandonner le type hint complètement, soit bricoler autour. La 7.1 ajoute le préfixe ? :

function findUser(?int $id): ?User {
    if ($id === null) return null;
    return $this->repository->find($id);
}

Ça semble mineur. Ce n’est pas le cas. Les types nullables font la différence entre une signature qui dit ce que fait une fonction et une qui ment par omission. Chaque codebase sur lequel j’ai travaillé a des fonctions qui peuvent retourner null. Maintenant on peut vraiment le dire plutôt que de le cacher dans un docblock.

Le type de retour void

Le complément du nullable : une fonction qui ne retourne intentionnellement rien :

public function process(Order $order): void {
    $this->dispatcher->dispatch(new OrderProcessed($order));
}

void rend l’intention explicite et empêche de retourner accidentellement une valeur depuis une fonction qui ne devrait pas. Combiné aux types nullables, le système de types de PHP en 7.1 est bien plus expressif qu’en 7.0.

La visibilité des constantes de classe

Un petit correctif mais bienvenu. Les constantes dans les classes étaient toujours publiques avant la 7.1. Maintenant :

class Config {
    private const DB_PASSWORD = 'secret';
    protected const VERSION = '2.0';
    public const MAX_RETRIES = 3;
}

Garder les détails d’implémentation privés, ça compte. Ça aurait dû exister depuis le début.

Attraper plusieurs exceptions

try {
    // ...
} catch (InvalidArgumentException | RuntimeException $e) {
    // gérer les deux
}

Évite un bloc catch dupliqué quand deux exceptions nécessitent un traitement identique. Simple, utile.

Déstructurer des tableaux sans list()

list() est dans PHP depuis la 4.0 et a toujours semblé un peu à côté syntaxiquement. La 7.1 ajoute un raccourci avec [] qui se lit bien plus naturellement :

[$first, $second] = $coordinates;

foreach ($rows as [$id, $name, $email]) {
    // ...
}

Elle gagne aussi le support des clés, ce qui rend la déstructuration de tableaux associatifs enfin utilisable :

['id' => $id, 'name' => $name] = $user;

foreach ($records as ['id' => $id, 'status' => $status]) {
    // ...
}

Avant ça, extraire des clés nommées d’un tableau signifiait soit extract() (qui déverse tout dans le scope et invite les collisions) soit un tas d’assignations individuelles. C’est juste plus propre.

Le type iterable

Si on écrit une fonction qui accepte soit un tableau soit un générateur, il n’y avait pas de type hint propre pour ça en 7.0. On typait soit en array et on excluait silencieusement les générateurs, soit on abandonnait le hint complètement :

function processItems(iterable $items): void {
    foreach ($items as $item) {
        $this->handle($item);
    }
}

iterable accepte tout ce sur quoi on peut faire un foreach : les tableaux et les implémentations de Traversable. Ça fonctionne aussi comme type de retour. Pas dramatique, mais ça comble un vrai manque.

Les offsets négatifs sur les chaînes

L’indexation de chaînes avec [] ou {} accepte maintenant les valeurs négatives, en comptant depuis la fin :

$str = 'hello';
echo $str[-1]; // "o"
echo $str[-2]; // "l"

Plusieurs fonctions de chaînes ont reçu le même traitement : strpos(), substr(), substr_count() et d’autres acceptent maintenant un offset négatif. Cohérent avec ce que Python fait depuis toujours. Mieux vaut tard que jamais.

Closure::fromCallable()

Avant ça, convertir un callable (comme [$object, 'method'] ou une chaîne nom de fonction) en une vraie Closure nécessitait Closure::bind() ou bindTo() avec une gestion de portée délicate. La 7.1 ajoute une méthode de fabrique statique :

class Processor {
    private function transform(string $value): string {
        return strtoupper($value);
    }

    public function getTransformer(): Closure {
        return Closure::fromCallable([$this, 'transform']);
    }
}

La closure résultante capture le bon $this et la bonne portée. C’est particulièrement utile quand on passe des méthodes comme callbacks à des fonctions qui attendent un callable, ou quand on construit des pipelines.

ArgumentCountError

En PHP 7.0, appeler une fonction définie par l’utilisateur avec trop peu d’arguments générait un warning et l’exécution continuait avec des paramètres remplis à null. En 7.1, ça lève une ArgumentCountError :

function connect(string $host, int $port): void { /* ... */ }

try {
    connect('localhost'); // Lève ArgumentCountError
} catch (\ArgumentCountError $e) {
    // ...
}

ArgumentCountError étend TypeError, qui étend Error. Les call sites qui se dégradaient silencieusement auparavant échouent maintenant bruyamment. C’est un risque de migration si on a du code qui comptait sur le comportement permissif, mais honnêtement, c’est la bonne décision.

La 7.1 est le genre de version qui fait davantage faire confiance à une plateforme. La core team regardait clairement les frictions, pas seulement les titres à faire valoir.

Le chiffre phare : 2x plus rapide que PHP 5.6. Ce n’est pas un benchmark cherry-pick — c’est la médiane sur des applications réelles. Le Zend Engine a été réécrit pour utiliser une nouvelle représentation interne des valeurs, ce qui réduit significativement l’utilisation mémoire et diminue les allocations. Sur un projet, le temps de réponse moyen a chuté de 40% sans aucune modification du code. On met à jour, et ça va plus vite.

Mais les performances ne sont pas la partie la plus intéressante.

Les types, enfin

PHP a eu les type hints pour les objets depuis la 5.0, pour les tableaux depuis la 5.1. En 7.0, on peut enfin déclarer des types scalaires pour les paramètres de fonctions et les valeurs de retour :

function add(int $a, int $b): int {
    return $a + $b;
}

En mode strict (declare(strict_types=1)), passer un float à cette fonction lève une TypeError. En mode coercitif par défaut, PHP convertit la valeur. Cette distinction compte : le mode strict est par fichier, on peut donc l’adopter progressivement sans tout casser d’un coup.

Les déclarations de type de retour constituent l’autre moitié. Placer l’intention dans la signature plutôt que dans un docblock signifie que c’est le moteur qui l’applique, pas un code reviewer à moitié endormi.

L’opérateur null coalescent

?? est petit mais utilisé en permanence :

$username = $_GET['user'] ?? 'guest';

Ça remplace isset($_GET['user']) ? $_GET['user'] : 'guest'. Il se chaîne aussi : $a ?? $b ?? $c. Après des années de bruit avec isset(), ça seul valait la mise à jour.

La partie qui casse

La refonte de la gestion des erreurs est le vrai risque lors de la migration. Beaucoup d’erreurs fatales sont maintenant des exceptions Error, attrapables mais différentes des Exception. Le code qui comptait sur les erreurs fatales pour stopper l’exécution silencieusement a maintenant besoin d’une gestion explicite. La suppression d’erreurs avec @ fonctionne aussi différemment par endroits.

Lire le guide de migration avant de toucher une appli en production. Le gain est réel, mais le fossé entre 5.6 et 7.0 est le plus large que PHP ait jamais eu.

L’opérateur vaisseau spatial

<=> est un opérateur de comparaison combiné qui retourne -1, 0 ou 1. Il est surtout là pour le tri :

usort($users, function ($a, $b) {
    return $a->age <=> $b->age;
});

Avant ça, un comparateur de tri personnalisé était un petit exercice de mémoire arithmétique. $a - $b fonctionne pour les entiers mais plante silencieusement pour les flottants. <=> fait ce qu’il faut pour chaque type comparable.

Les classes anonymes

On peut maintenant instancier une classe définie en ligne, sur le moment, sans lui donner de nom :

$logger = new class($config) implements LoggerInterface {
    public function __construct(private array $config) {}

    public function log(string $message): void {
        file_put_contents($this->config['path'], $message . PHP_EOL, FILE_APPEND);
    }
};

Le cas d’usage canonique, ce sont les doublures de test et les implémentations d’interface ponctuelles qui ne méritent pas un fichier. Ça supprime une vraie friction : le fossé entre “j’ai besoin d’un objet” et “je dois créer un fichier de classe pour un truc de 10 lignes”.

Aléatoire cryptographiquement sûr

Les rand() et mt_rand() de PHP 5 n’ont jamais été conçus pour la sécurité. La 7.0 ajoute deux fonctions qui le sont :

$token = bin2hex(random_bytes(32)); // token hexadécimal de 64 caractères
$pin   = random_int(100000, 999999);

random_bytes() puise dans le CSPRNG du système d’exploitation. random_int() enveloppe ça pour les entiers. Ces fonctions remplacent tous les schémas de génération de tokens maison qui faisaient ça mal en silence, ce qui représente la majorité d’entre eux.

Les déclarations use groupées

Avant 7.0, importer cinq éléments depuis le même namespace nécessitait cinq instructions use. Maintenant :

use App\Model\{User, Order, Product};
use function App\Helpers\{formatDate, slugify};
use const App\Config\{MAX_RETRIES, TIMEOUT};

Petite amélioration ergonomique, mais qui réduit le bruit visuel en haut des fichiers avec des hiérarchies de namespaces profondes.

Les générateurs ont grandi

Les générateurs en 5.5 étaient intéressants mais incomplets. La 7.0 ajoute deux choses. Premièrement, un générateur peut maintenant avoir une valeur de retour, accessible après la fin de l’itération :

function process(): Generator {
    yield 'step 1';
    yield 'step 2';
    return 'done';
}

$gen = process();
foreach ($gen as $step) { /* ... */ }
echo $gen->getReturn(); // "done"

Deuxièmement, yield from délègue à un autre générateur ou itérable, en transmettant transparemment les valeurs et valeurs de retour :

function inner(): Generator {
    yield 1;
    yield 2;
    return 'inner done';
}

function outer(): Generator {
    $result = yield from inner();
    echo $result; // "inner done"
    yield 3;
}

Ça rend la composition de générateurs pratique sans avoir à câbler manuellement les valeurs entre eux.

Closure::call()

Une façon plus directe de lier une closure à un objet et de l’appeler immédiatement :

class Counter {
    private int $count = 0;
}

$increment = function (int $by): void {
    $this->count += $by;
};

$increment->call(new Counter(), 5);

bindTo() existait avant mais nécessitait deux étapes. call() les fusionne et est plus rapide à l’exécution car il évite la création d’une closure intermédiaire.

Syntaxe d’échappement Unicode dans les chaînes

On peut maintenant intégrer des caractères Unicode directement dans les chaînes entre guillemets doubles ou les heredocs via un point de code :

echo "\u{1F418}"; // 🐘
echo "\u{00E9}";  // é

C’est mieux que de copier-coller des caractères depuis une table Unicode dans les fichiers sources, ce que les gens faisaient vraiment.

Un unserialize() plus sûr

unserialize() a une longue histoire d’être un vecteur d’attaques par injection d’objets. La 7.0 ajoute une option allowed_classes :

$data = unserialize($input, ['allowed_classes' => false]);
$data = unserialize($input, ['allowed_classes' => [User::class, Order::class]]);

Passer false empêche toute instanciation d’objet pendant la désérialisation. C’est le comportement par défaut à adopter quand on désérialise des données non fiables.

:1234: Division entière

intdiv() est une division entière explicite sans intermédiaire flottant :

$pages = intdiv(count($items), $perPage); // int, pas besoin de cast

Oui, on pourrait caster le résultat d’une division. intdiv() rend l’intention claire et évite les cas limites de précision flottante que le cast introduit pour les grands nombres.

Les constantes en tableaux

Avant 7.0, define() n’acceptait que les valeurs scalaires. Les tableaux fonctionnaient avec const au niveau de la classe ou du namespace mais pas avec define(). Maintenant si :

define('HTTP_METHODS', ['GET', 'POST', 'PUT', 'DELETE', 'PATCH']);

Utile pour la configuration qui doit être une constante mais qui vit en dehors d’une classe.

Des assertions avec des dents

assert() a reçu une vraie refonte. En PHP 5, les assertions étaient un eval de chaînes à l’exécution. Maintenant elles peuvent lever des exceptions et être complètement supprimées en production avec zéro overhead :

// Dans php.ini ou au bootstrap :
// assert.active = 1 (dev), 0 (prod)
// assert.exception = 1

assert($user->isVerified(), new \LogicException('Unverified user reached checkout'));

Quand assert.active = 0, l’expression n’est jamais évaluée. Quand c’est activé, une assertion qui échoue lève directement l’exception fournie. C’est enfin un outil qu’on peut utiliser sans honte.

La refonte de session_start()

session_start() accepte maintenant un tableau d’options qui surchargent les directives php.ini pour cet appel :

session_start([
    'cookie_lifetime' => 86400,
    'cookie_secure'   => true,
    'cookie_httponly'  => true,
    'cookie_samesite' => 'Lax',
]);

Avant ça, on définissait soit les options globalement dans php.ini, soit on appelait ini_set() avant session_start(). Aucune des deux n’était top quand on avait besoin de configurations de session différentes dans différentes parties d’une appli.