Re: [PHP-DEV] Re: [RFC] [Discussion] Literal Scalar Types

Hi

Am 2026-06-29 13:52, schrieb Seifeddine Gmati:
> I'm planning to take this RFC to a vote next week. I just wanted to
> check in since there hasn't been any discussion after the last update.
> 
> Any concerns regarding this?

FWIW: The list is *extremely* busy right now with (new) proposals that I 
feel would do well waiting until after the feature freeze. Personally 
I'm having troubles keeping up with all the discussion, RFCs, and code 
review. I assume that others feel similar, so that would explain the 
absence of feedback.

I've given the RFC another full read and have the following remarks:

1.

The RFC specifies “Integer literals, with an optional leading minus 
sign: 1, 0, -1.”, are leading `+` signs also legal? What about multiple 
signs or spaces? From what I see the tokenizer does not currently 
support a sign for number literals at all, so `-1` is tokenized as a 
(unary) minus applied to `1`, so the behavior is not immediately 
obvious.

2.

> PHP's direction of travel. The ecosystem has moved steadily towards 
> strict_types=1

I don't believe this statement is accurate. What has happened is “make 
the non-strict_types mode more predictable” to the extent that 
`strict_types=1` has actually become less safe. From what I see in the 
ecosystem, `strict_types=1` is also not widely used.

I believe that “making literal types strict” is the correct choice (for 
the consistency reasons), but I don't think this specific statement is 
backed up by evidence.

3.

> A literal denotes a single value and carries no interface, so it cannot 
> take part in an intersection type. 1&Foo is a parse error.

I don't think making this a parser error is in the interest of 
“providing useful error messages”. This should be a compiler error that 
clearly indicates the issue, just like `function foo(true&Foo $foo) { }` 
is a compiler error.

4.

For the “Ecosystem” impact: I believe there is also an impact to 
anything consuming types from Reflection (such as mappers). This is 
implied with the “Reflection impact”, but could be spelled out more 
explicitly.

------------------

As for the proposal itself: As already indicated in my previous emails, 
I don't see much value in supporting literal types for newly written 
code. I very likely won't vote in favor, but am still undecided about 
“Abstain” and “No”.

I'm also concerned about folks shooting themselves in the foot with type 
checking performance for “wide unions of literal types”. It might make 
sense to provide a dedicated performance section in the RFC. From what I 
see using a quick glance, the current implementation is O(n) 
left-to-right, which means that passing 9 to `0|1|2|3|4|5|6|7|8|9` will 
be slower than passing 0. I understand this issue already exists with 
union types, but unions between two different class types are 
comparatively rare and unions wider then 2 are even rarer.

Best regards
Tim Düsterhus