Le point n’est pas une modification de runtime immédiate: le RFC vise des dépréciations en 8.6, puis des suppressions en PHP 9, sauf exceptions précisées au cas par cas. Pour les équipes PHP, c’est le début de la fenêtre d’audit: le code qui passe aujourd’hui peut commencer à produire des signaux de compilation avant le prochain saut majeur.
Un vote, plusieurs cibles, seuil élevé
Chaque fonctionnalité proposée est soumise à un vote séparé. L’adoption requiert une majorité des deux tiers. Rien ne permet donc encore de considérer l’ensemble de la liste comme acquis: il faut suivre le résultat de chaque proposition, pas seulement l’existence du RFC annuel.
Le mécanisme reste toutefois clair. Une dépréciation en 8.6 prépare une suppression en PHP 9. Le coût n’est pas uniforme: certaines syntaxes seront remplaçables automatiquement, d’autres révèlent des branches de contrôle où le comportement actuel masque déjà un défaut.
list: migration mécanique, dette inutile
Le RFC cible notamment la construction list, utilisée pour déstructurer un tableau:
list($id, $status) = $row;Depuis PHP 7.1, la syntaxe courte fournit la même sémantique dans les mêmes positions:
[$id, $status] = $row;Imbrication, éléments ignorés et déstructuration par clés: les deux écritures sont interchangeables selon le texte du RFC. Si la proposition est adoptée, l’usage de list déclencherait une dépréciation à la compilation; le comportement à l’exécution ne changerait pas à ce stade.
C’est le cas simple du lot. La transformation est annoncée comme automatisable: un grep ciblé, une règle de refactoring et une passe de CI suffisent à éliminer la syntaxe. Le RFC relève 12 275 occurrences dans 5 545 fichiers pour son analyse d’impact. Ce n’est pas un problème d’allocation mémoire ou de GC: c’est une surface syntaxique redondante que les analyseurs, les IDE et les nouveaux contributeurs doivent continuer à traiter sans gain fonctionnel.
Le vrai audit: finally et les chemins de sortie
Le RFC met aussi en lumière un motif plus dangereux: un return exécuté depuis un bloc finally alors que le try ou le catch est déjà en train de retourner ou de lever une exception. Dans cette configuration, le return du finally peut écraser la valeur de retour ou faire disparaître l’exception.
try {
throw new RuntimeException;
} finally {
return null;
}Le résultat est silencieux: l’appelant peut recevoir une valeur normale alors qu’une exception venait d’être levée. Ni warning, ni notice, ni trace ne signalent nécessairement la perte. Ce n’est donc pas une simple question de compatibilité PHP 9; c’est un chemin de contrôle à repérer avant qu’un changement de version ne le rende visible dans les logs ou les pipelines.
À vérifier maintenant: les usages de list, les return dans les finally, puis les zones touchées par les évolutions annoncées sur readonly et les arguments de fonctions. Verdict: audit à lancer en prod, migration à appliquer seulement après validation des votes.