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

On Mon, 29 Jun 2026 at 19:18, Tim Düsterhus <[email protected]> wrote:
>
> 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.

Hi Tim,

Thanks for the read, and no worries about the timing. The list is clearly
busy right now, so I appreciate you getting to it.

All four remarks are addressed in v0.3, which I've just pushed:

> 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?

A single leading unary `+` or `-` is accepted, so both `-1` and `+1` are
legal, and `+1` denotes the same type as `1`.

> 2. I don't believe this statement is accurate. ... 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.

Agreed, and I've dropped the claim entirely. The case for strict matching
now rests only on consistency with `null`/`true`/`false`, and on the single
rule that a type whose identity is one value matches only that value.

> 3. I don't think making this a parser error is in the interest of
> "providing useful error messages". This should be a compiler error ...

Done, it's a compile-time error now, consistent with how `function
foo(true&Foo $foo) {}` is handled.

> 4. For the "Ecosystem" impact: I believe there is also an impact to
> anything consuming types from Reflection (such as mappers).

Spelled out explicitly now.

> 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.

Added. It states plainly that the membership check is O(n) left-to-right,
uses your exact example (passing `9` to `0|1|2|3|4|5|6|7|8|9` scans all ten
members, while `0` returns immediately), and notes that although this is
the same behaviour every union type already has, literal unions invite much
larger member counts, so the footgun is more reachable here.

That example also prompted a Future Scope note, which I've added. If
integer range types were later introduced, the engine can collapse a
contiguous run like `0|1|...|9` into a single range `0..9` and check it
with two bound comparisons instead of a linear scan, turning the wide-union
cost into O(number of ranges). This is what we already do in Mago, so I'm
fairly confident it will carry over to the engine. See
https://github.com/carthage-software/mago/blob/14bf9e84884117ff385fa4ebfd90dd08622e7359/crates/codex/src/ttype/atomic/scalar/int.rs#L818-L958
<https://github.com/carthage-software/mago/blob/14bf9e84884117ff385fa4ebfd90dd08622e7359/crates/codex/src/ttype/atomic/scalar/int.rs#L818-L958>

Note: The implementation has not been updated, I will address it later
when/if the RFC is accepted

Best regards,
Seifeddine