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
