Re: [RFC] [Discussion] Literal Scalar Types

From: Date: Mon, 15 Jun 2026 19:41:36 +0000
Subject: Re: [RFC] [Discussion] Literal Scalar Types
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-131297@lists.php.net to get a copy of this message
On Mon, 15 Jun 2026 at 18:20, Sarina Corrigan <sarina.corrigan@gmail.com> wrote: > > It may be worth mentioning that within the Pattern Matching RFC future scope, and mentioned a couple times within the discussion thread for the RFC, there is a similar proposal that would allow for this without using specific literal types. > > It's outlined in https://github.com/Crell/php-rfcs/blob/master/pattern-matching/future.md under "Parameter or return guards" > > It would allow for: > > ``` > function setLogLevel (string $level is 'debug' | 'info' | > 'warning' | 'error'): void {} > ``` > > Of course, I don't think that a potential future scope of an in-draft RFC is reason to dismiss a more direct implementation of literal scalar types, but it may be useful to compare other ways we could achieve the same functionality. I personally find pattern matching within parameter/return types more versatile while keeping direct typing system more simplified. Specifically for a range feature that Ben Ramsey brought up, pattern matching for parameters seems much more appropriate. > > All that being said, I would gladly welcome literal scalar types. > > On Sun, Jun 14, 2026, 21:24 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. >> >> - RFC: https://wiki.php.net/rfc/literal_scalar_types >> - Implementation: https://github.com/php/php-src/pull/22314 >> >> Thanks, >> Seifeddine. Hi Sarina, Thanks for the pointer, that is a good read. I don't think literal scalar types conflict with the pattern matching future scope at all. The way I see it, a pattern is, or at least should be, a type. $foo is Foo { x: 10 } is really asking "does $foo have the type Foo with x equal to 10", and I would happily see us later allow `Foo { x: 10 }` as a type on its own. The one thing a pattern adds over a type is binding: capturing a value in place of a sub-type, e.g. ``` if ($foo is Foo { x: $x }) { /* $x is bound here */ } ``` which a plain type declaration cannot do. On the specific syntax in that document: ``` function setLogLevel(string $level is 'debug' | 'info' | 'warning' | 'error'): void {} ``` reads as redundant to me. The string contributes nothing once the value set is given, so with literal scalar types the same intent is simply: ``` function setLogLevel('debug' | 'info' | 'warning' | 'error' $level): void {} ``` So I see the two as complementary rather than competing: literal types provide the value-as-type building block, and pattern matching can build on top of it for binding and destructuring. Glad to hear you would welcome the feature. Cheers, Seifeddine

« previous php.internals (#131297) next »