Re: [RFC] [Discussion] Literal Scalar Types

On Mon, 15 Jun 2026 at 03:03, David Gebler <davidgebler@gmail.com> wrote: > > On Mon, Jun 15, 2026 at 2:24 AM Seifeddine Gmati <azjezz@carthage..software> wrote: >> >> Hello Internals, >> >> I'd like to start the discussion on a new RFC adding literal scalar >> types to PHP. > > > Prima facie, I feel like enums already do what this aims to achieve, much better. > >> >> >> - RFC: https://wiki.php.net/rfc/literal_scalar_types >> - Implementation: https://github.com/php/php-src/pull/22314 >> >> Thanks, >> Seifeddine. Hi David, I agree enums are the better fit for a lot of cases. but not all. 1. describing APIs that already exist. array_filter's $mode really accepts 0|1|2, but it's typed int because that's all the type system can say today. we can't retype it as an enum without breaking every caller. a literal union lets the signature state the actual contract. 2. ad-hoc / open value sets. for a library, "ascii"|"utf-8" would need its own named symbol ( enum BorderStyle { case Ascii; case Utf8 }, a new file, an import ) for what is really two strings. and because an enum is a closed set, adding a third style later breaks any consumer that match-es over it without a default. widening the union on a parameter ( "ascii"|"utf-8"|"unicode" ) is contravariant, so it breaks nobody. 3. scalar interop. a literal value is the scalar, so it works as an array key, compares with ===, round-trips through json, etc. enum cases are objects and don't. so they overlap a lot, but literal unions reach things enums structurally can't: existing scalar APIs, and open sets that grow without a BC break. Cheers, Seifeddine.