On Mon, 15 Jun 2026 at 18:20, Sarina Corrigan <[email protected]>
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 <[email protected]>
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
