Re: [RFC] [Discussion] Literal Scalar Types
| From: | Seifeddine Gmati | Date: | Mon, 15 Jun 2026 19:42:54 +0000 |
| Subject: | Re: [RFC] [Discussion] Literal Scalar Types | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131298@lists.php.net to get a copy of this message | ||
On Mon, 15 Jun 2026 at 19:25, Lars Nielsen <lars@lfweb.dk> wrote:
>
>
> Den 15. jun. 2026 kl. 19.23 skrev Sarina Corrigan <sarina.corrigan@gmail.com>:
>
>
> 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,
> This sounds very promising. But I would be confused about receiving a TypeError when just the
> value of the parameter is wrong.
>
> As described in the RFC if I send 4 to a parameter that could only be 1, 2 or 3. I would expect
> a TypeError if I sent “abc” ?
>
> Kind regards
> Lars Nielsen
Hi Lars,
I think the confusion comes from treating "type" and "value" as two
separate things, which is the usual mental model. Literal scalar types
deliberately blur that line: each value is itself a type, a unit type
containing exactly one value.
So
1|2|3 is not "an int that happens to be restricted", it is the
union of three unit types 1, 2 and 3. Under that view, both
4
and "abc" fail for the same reason: neither is a member of the
declared type. There is no separate "the value is wrong" category, it
is all type membership, so a TypeError is the consistent outcome.
It is the same thing that already happens with the true type today:
passing false to a true parameter is a TypeError, even though
both are booleans.