The Php Times

Le contributeur PHP Seifeddine Gmati a ouvert la discussion sur un nouveau RFC intitulé « Literal Scalar Types » (implémentation : pull request php-src #22314). La proposition permettrait aux déclarations de type de désigner directement des valeurs scalaires précises, comme -1|0|1 ou "ascii"|"utf-8", plutôt que les seuls types de base int ou string.

Gmati fait valoir que la fonctionnalité couvre des cas que les enums ne peuvent pas structurellement atteindre : des API existantes déjà typées int ou string (comme le paramètre $mode d'array_filter) pourraient recevoir un contrat plus précis sans casser le code appelant ; des ensembles de valeurs ouverts (noms d'encodage, par exemple) pourraient s'élargir de façon contravariante sans forcer les consommateurs à ajouter un cas par défaut ; enfin, une valeur littérale reste un scalaire pur, utilisable comme clé de tableau, comparable avec === et compatible JSON sans les conversions ->value/::from() qu'exigent les enums.

Plusieurs relecteurs ont contesté ces arguments. David Gebler a douté que les enums soient aussi fragiles face à l'ajout de nouveaux cas. Tim Düsterhus a cité la migration de l'enum RoundingMode (issue du RFC « Correctly name the rounding mode ») comme preuve qu'on peut retyper une API scalaire vers un enum via un chemin de dépréciation, et a mentionné une ébauche « non_exhaustive_marker » pour formaliser les enums non exhaustifs.

Sur le périmètre, le RFC exclut la référence à des constantes ou des cas d'enum en position de type (ambiguïté avec les noms de classe ; une valeur d'enum est une expression à l'exécution, pas un littéral), ainsi que NAN/INF, qui sont des constantes et non des littéraux. Le mélange de types littéraux avec des types de base plus larges dans une union (par exemple int|'bar') est explicitement autorisé par conception.

Le point le plus disputé concerne les littéraux flottants : Düsterhus et Larry Garfield ont estimé que les floats sont trop imprécis pour une correspondance exacte (0.1 + 0.2 !== 0.3) et ont recommandé de limiter la fonctionnalité aux littéraux int et string ; Gmati s'est dit désormais enclin à abandonner le support des floats.

Andreas Heigl a suggéré des plages numériques (par exemple int 1..PHP_INT_MAX) comme suite logique ; Gmati a approuvé l'idée tout en estimant qu'elle mérite un RFC séparé vu sa complexité propre (bornes, inclusion, coercion). Bob Weinand et Sarina Corrigan ont évoqué le pattern matching (via la proposition de portée future « Parameter or return guards » du RFC Pattern Matching de Larry Garfield et Ilija) comme alternative potentiellement plus générale ; Gmati considère les types littéraux comme une brique distincte et complémentaire du système de types, utile aussi aux futurs types de tuples et de formes de tableaux (« array shapes »).

Gmati a également proposé de scinder le futur vote en questions séparées portant sur les littéraux string, int et float, ainsi que sur le mode de coercion (correspondance stricte par identité, comme pour true/false/null, ou coercion classique).