Der PHP-Mitwirkende Seifeddine Gmati hat die Diskussion zu einem neuen RFC namens „Literal Scalar Types" eröffnet (Implementierung: php-src-Pull-Request #22314). Der Vorschlag erlaubt es, Typdeklarationen direkt auf konkrete Skalarwerte zu beschränken, etwa -1|0|1 oder "ascii"|"utf-8", statt nur allgemeine Typen wie int oder string zu verwenden.

Gmati argumentiert, das Feature decke Bereiche ab, die Enums strukturell nicht erreichen: Bestehende, bereits als int oder string typisierte APIs (etwa der $mode-Parameter von array_filter) könnten präzisere Verträge bekommen, ohne aufrufenden Code zu brechen; offene Wertemengen (z. B. Encoding-Namen) ließen sich durch kontravariante Erweiterung der Union gefahrlos um neue Werte ergänzen; und literale Werte blieben echte Skalare, die als Array-Schlüssel, mit === und beim JSON-Roundtrip funktionieren, ohne die ->value/::from()-Konvertierung, die Enums erfordern.

Kritiker widersprachen an mehreren Stellen. David Gebler bezweifelte, dass Enums gegenüber neuen Fällen so zerbrechlich seien wie behauptet. Tim Düsterhus verwies auf die bestehende Migration des RoundingMode-Enums (aus dem RFC „Correctly name the rounding mode") als Beleg dafür, dass sich skalare APIs über einen Deprecation-Pfad sicher zu Enums migrieren lassen, und nannte einen Entwurf namens „non_exhaustive_marker" für nicht-erschöpfende Enum-Matches.

Beim Geltungsbereich schließt das RFC Konstanten- und Enum-Case-Referenzen in Typpositionen aus (Mehrdeutigkeit mit Klassennamen; Enum-Werte sind Laufzeitausdrücke, keine Literale) sowie NAN/INF, da dies Konstanten und keine Literale sind. Die Mischung von Literal-Typen mit breiteren Basistypen in einer Union (z. B. int|'bar') ist ausdrücklich vorgesehen.

Am umstrittensten waren Float-Literale: Düsterhus und Larry Garfield argumentierten, Floats seien für exakten Werteabgleich zu ungenau (0.1 + 0.2 !== 0.3) und plädierten dafür, das Feature auf int und string zu beschränken; Gmati signalisierte, Float-Unterstützung vorerst fallen zu lassen.

Andreas Heigl schlug numerische Bereiche (etwa int 1..PHP_INT_MAX) als logische Erweiterung vor; Gmati stimmte zu, hält dies aber wegen zusätzlicher Komplexität (Grenzen, Ein-/Ausschluss, Koercion) für ein eigenes RFC. Bob Weinand und Sarina Corrigan brachten Pattern Matching (gemäß dem Future-Scope-Vorschlag „Parameter or return guards" aus dem Pattern-Matching-RFC von Larry Garfield und Ilija) als mögliche allgemeinere Alternative ins Spiel; Gmati sieht Literal-Typen jedoch als eigenständigen, ergänzenden Baustein des Typsystems, der künftigen Array-Shape- und Tupel-Typen zuarbeitet.

Gmati schlug zudem vor, die künftige Abstimmung in getrennte Fragen zu string-, int- und float-Literalen sowie zur Koercion (identitätsbasiert wie bei true/false/null vs. koerzierend) aufzuteilen.