Novembre 2021 a marqué la sortie de PHP 8.1, avec parmi ses nouveautés un type de retour discret mais utile : never. Contrairement à void, qui signale qu’une fonction ne retourne aucune valeur mais termine normalement son exécution, never annonce qu’une fonction ne se termine jamais normalement — elle redirige, elle meurt, ou elle lève systématiquement une exception.
Ce type reste peu utilisé dans les projets WordPress, en partie parce que le cœur lui-même n’a pas encore adopté ce niveau de typage pour ses propres fonctions. Il trouve pourtant un usage naturel dans les fonctions utilitaires personnalisées d’une extension qui redirigent ou arrêtent systématiquement le script.
La différence entre void et never
Une fonction typée void peut légitimement se terminer en atteignant sa dernière ligne, sans instruction return explicite, ou avec un simple return; sans valeur. Une fonction typée never ne peut, elle, jamais atteindre sa dernière ligne normalement : elle doit systématiquement rediriger le flux d’exécution ailleurs, via une redirection HTTP suivie d’un arrêt, un throw, ou un appel à une fonction elle-même typée never.
Si une fonction déclarée never se termine malgré tout par un chemin qui revient normalement — un if mal fermé, par exemple — PHP lève une erreur fatale au moment de l’exécution de ce chemin. Le type agit donc comme une promesse vérifiée à l’exécution, pas seulement comme une annotation de documentation.
Un cas d’usage concret : une fonction de garde

Imaginons une extension qui centralise l’arrêt du script en cas de configuration invalide, avec un message cohérent sur tout le projet :
function extension_arreter_avec_erreur( string $message ): never {
wp_die(
esc_html( $message ),
esc_html__( 'Configuration invalide', 'mon-extension' ),
array( 'response' => 500 )
);
}
function extension_verifier_cle_api(): void {
$cle = get_option( 'extension_cle_api' );
if ( empty( $cle ) ) {
extension_arreter_avec_erreur( __( 'La clé API n\'est pas configurée.', 'mon-extension' ) );
}
// Le code ci-dessous sait, grâce au type never, que $cle est forcément non vide ici.
}
Le type never apporte ici une information précieuse pour un outil d’analyse statique : il sait que si extension_arreter_avec_erreur() est appelée, aucune instruction suivante dans extension_verifier_cle_api() ne s’exécutera dans cette branche, et peut donc affiner ses vérifications sur le code qui suit.
Ce que ce type change concrètement au quotidien
- Il documente une intention que les commentaires seuls ne garantissent pas : une fonction qui ne « revient » jamais, au sens propre.
- Il aide les outils d’analyse statique à détecter du code mort placé après un appel à une fonction typée
never. - Il reste rarement nécessaire en dehors de fonctions utilitaires très spécifiques : la grande majorité du code d’une extension n’a pas vocation à interrompre systématiquement l’exécution.
Une erreur fréquente à éviter
Typer never une fonction qui contient un wp_die() conditionnel, exécuté seulement dans certains cas, constitue une erreur de typage : PHP considérera que la fonction peut légitimement continuer au-delà de la condition, et lèvera une erreur si ce chemin de continuation est effectivement emprunté. never ne convient qu’à une fonction dont chaque chemin d’exécution possible se termine par une interruption, sans exception.
Réserver le type never aux fonctions dont on peut garantir, en relisant chaque branche, qu’aucune ne revient jamais normalement : dans le doute, void reste le choix le plus sûr.
Compatibilité et adoption progressive
Comme pour toute nouveauté de typage PHP, ce type ne peut être utilisé que sur un hébergement tournant au minimum en PHP 8.1, ce qu’il convient de vérifier avant de l’ajouter à l’en-tête d’une extension déjà distribuée. Il ne s’agit d’ailleurs pas d’un prérequis pour que le reste du code fonctionne : une extension peut très bien continuer à fonctionner sans ce type, qui reste un raffinement plutôt qu’une nécessité.
En résumé
Le type never, introduit par PHP 8.1, comble un vide précis dans le système de types du langage : signaler qu’une fonction n’atteint jamais une fin normale. Son usage reste ciblé — fonctions de garde, wrappers de redirection, utilitaires qui interrompent systématiquement le script — mais quand la situation s’y prête, il rend l’intention du code explicite pour les humains comme pour les outils d’analyse statique.