El colaborador de PHP Seifeddine Gmati abrió el debate sobre un nuevo RFC llamado «Literal Scalar Types» (implementación: pull request de php-src #22314). La propuesta permitiría que las declaraciones de tipo referencien valores escalares concretos, como -1|0|1 o "ascii"|"utf-8", en lugar de limitarse a tipos base como int o string.

Gmati sostiene que la función cubre casos que los enums no pueden alcanzar estructuralmente: las API existentes ya tipadas como int o string (por ejemplo, el parámetro $mode de array_filter) podrían obtener un contrato más preciso sin romper el código que las llama; los conjuntos de valores abiertos (nombres de codificación, por ejemplo) podrían ampliarse de forma contravariante sin obligar a los consumidores a añadir un caso por defecto; y un valor literal sigue siendo un escalar puro, utilizable como clave de array, comparable con === y compatible con JSON sin las conversiones ->value/::from() que exigen los enums.

Varios revisores cuestionaron estos argumentos. David Gebler dudó de que los enums sean tan frágiles ante nuevos casos como se afirmaba. Tim Düsterhus citó la migración del enum RoundingMode (del RFC «Correctly name the rounding mode») como prueba de que una API escalar puede retiparse a un enum mediante una ruta de deprecación, y mencionó un borrador llamado «non_exhaustive_marker» para formalizar enums no exhaustivos.

En cuanto al alcance, el RFC excluye referenciar constantes o casos de enum en posición de tipo (ambigüedad con nombres de clase; un valor de enum es una expresión en tiempo de ejecución, no un literal), así como NAN/INF, que son constantes y no literales. Mezclar tipos literales con tipos base más amplios en una unión (por ejemplo, int|'bar') está permitido explícitamente por diseño.

El punto más debatido fueron los literales de punto flotante: Düsterhus y Larry Garfield argumentaron que los floats son demasiado imprecisos para una coincidencia exacta (0.1 + 0.2 !== 0.3) y recomendaron limitar la función a literales int y string; Gmati indicó que ahora se inclina por retirar el soporte de floats.

Andreas Heigl propuso rangos numéricos (por ejemplo, int 1..PHP_INT_MAX) como siguiente paso lógico; Gmati coincidió, pero considera que merece un RFC propio por su complejidad adicional (límites, inclusión, coerción). Bob Weinand y Sarina Corrigan plantearon el pattern matching (según la propuesta de alcance futuro «Parameter or return guards» del RFC de Pattern Matching de Larry Garfield e Ilija) como posible alternativa más general; Gmati considera los tipos literales una pieza distinta y complementaria del sistema de tipos, útil también para futuros tipos de tuplas y «array shapes».

Gmati también propuso dividir la futura votación en preguntas separadas sobre literales de string, int y float, y sobre el modo de coerción (coincidencia estricta por identidad, como ocurre con true/false/null, o coerción habitual).