On Mon, 15 Jun 2026 at 19:25, Lars Nielsen <[email protected]> wrote: > > > Den 15. jun. 2026 kl. 19.23 skrev Sarina Corrigan <[email protected]>: > > > 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, > 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.
