On Mon, May 18, 2026, at 01:36, Seifeddine Gmati wrote:
> Hi Rob,
>
> The RFC enforces type-system structure at four places: declaration-site
> syntax and variance soundness, link-time inheritance arity and bound
> conformance, link-time parametric LSP (including the diamond-merge case I
> described), and runtime turbofish arity and bounds. The structural
> enforcement is substantial: the variance declared at the parameter (`+T`,
> `-T`, invariant by default) constrains how the parameter can be used,
> parametric LSP substitutes the bindings into method signatures at inheritance
> points, and turbofish forces explicit type arguments at call sites requiring
> disambiguation.
>
> What's not enforced is parametric flow analysis: tracking how a `T`-typed
> value flows through a method's body, narrowing it through control flow, and
> inferring its concrete type at a use site. That's the layer where tools
> currently diverge most, and you're right that this RFC doesn't directly
> resolve those disagreements.
>
> But the RFC does change the *shape* of the inference-disagreement problem in
> a way that helps. Today, tools have to guess what `new Collection([1])` means
> because there's no syntax to express the user's intent. The guesses differ.
> Once turbofish exists, tools can do two things they can't do now:
>
> 1. Simplify inference to only handle the unambiguous cases (where the type is
> clearly determinable from context and conventions), and emit a warning or
> error when inference would otherwise have to guess.
> 2. Recommend turbofish at sites where the user's intent is ambiguous, so the
> user can disambiguate explicitly with `new Collection::<int>([1])`.
>
> That moves the dev-UX problem from "different tools silently produce
> different inferred types" to "tools agree that the type is ambiguous,
> recommend turbofish, and the user disambiguates." The convergence point
> becomes the user's annotation, not the tool's heuristic. As Mago's maintainer
> I can tell you we'd lean into this shift hard. Our current inference
> heuristics are messy precisely because there's no other option; the moment
> turbofish exists, we'd simplify them to "be sure or ask the user."I'd expect
> PHPStan and Psalm to land in similar places eventually too.
>
> > Which means Box<A&B> works either way you want it to work. It could mean
> > A|B or A&B; the engine happily accepts either reading.
>
> Disagree. The reading of `Box<A&B>` is determined by Box's variance
> declaration. If `Box<+T>` declares T as covariant, then `Box<A&B>` is a
> subtype of `Box<A>` and `Box<B>` (intersection narrows for covariant
> positions). If `Box<-T>` declares T as contravariant, the relationship
> inverts: `Box<A&B>` is a supertype, and a `Box<A>` can be passed where
> `Box<A&B>` is expected. If T is invariant (the default), neither relationship
> holds and the engine treats `Box<A&B>` as a distinct type from `Box<A>` and
> `Box<B>`.
>
> So the engine has a definite reading; it just depends on the variance
> declared at Box. The interpretation isn't ambiguous, it's compositional.
> Tools that disagreed today on what `Box<A&B>` means would have to agree once
> variance is declared in syntax, because the variance is then a property of
> the language, not a tool-specific interpretation.
>
> I'd grant that for the common case of invariant T (which is the default and
> what most generic code will use) the type argument is opaque relative to
> subtyping, for example, `Box<A&B>` is not a subtype of `Box<A>` or `Box<B>`.
> That opacity is the bound-erasure trade. But it's a determinate opacity, not
> a "happily accepts either reading" one.
>
> Cheers,
> Seifeddine.
Hi Seifeddine,
I'm a bit confused. In your earlier email you said that tools currently can't
converge on simple generics correctness (and in your last email admitted even
your own tool was incorrect), but say that this will force them to converge. If
they've not been able to do so already, I have little faith that they will in
the future. In fact, if someone could get them in a room together to converge,
maybe we wouldn't need this RFC at all.
In regards to my Box<A&B> example. My apologies. I was collapsing two different
perspectives into one instead of being clear. I'm not talking about the engine;
I think your RFC is clear there. I'm talking about new users or users not using
any tooling to tell them they've got an error. T-typed positions inside Box are
checked against T's bound, not against A&B. So Box<A&B>'s internal value flow
is observationally identical to Box<A|B>'s, or Box<mixed>'s -- all accept and
produce values satisfying the bound. The static subtyping relationship is real
and enforced at link-time parametric LSP. It's invisible at runtime.
I understand this is the entire point of "type erasure", but it's a real
problem for new developers using PHP for the first time. A developer reasoning
at the value level gets no engine feedback distinguishing intersection from
union from arbitrary supertype.
Further, the runtime is silent in cases the RFC documents as enforced. The
Limitations section says: "the inherited or trait-imported function's signature
is substituted on the child - reflection sees the substituted types, the
link-time variance check uses them, and entry-side type checks inside the body
read the substituted parameter types." Tested on your PR branch:
class Box<T> {
public function test(T $v): T {
return $v;
}
}
class IntBox extends Box<int> {}
$b = new IntBox();
echo $b->test("hello"); // prints "hello"
Reflection reports `int` for the parameter type on `IntBox::test`, confirming
the metadata is substituted. But the entry-side check accepts the string,
contradicting the same sentence's claim that those checks read substituted
parameter types. The implementation does the metadata half and skips the
runtime-enforcement half, and the runtime-enforcement half is the part that
would catch the bug. The RFC text and the implementation disagree.
One thing I want to call out: the RFC template specifically asks you to address
PHP's "wide range of users" and consider "the consequences of making the
learning curve steeper with every new feature." The RFC engages with that
question for developers already inside the @template ecosystem by formalizing
existing practice, shortening code, reducing two-parallel-type-systems
cognitive load. What I don't see addressed anywhere is the new-user case: a
developer who's never seen generics encounters <T> in production code, writes
their own, runs it, gets no runtime feedback when their value-level intuition
diverges from the underlying expectations without using a tool. The IntBox case
above demonstrates the gap empirically: the developer writes what looks like
reasonable code, refreshes, and the output looks correct despite being wrong by
the engine's own claimed semantics. The template's procedural ask is engagement
with the full picture; what's been delivered is engagement with the favorable
half and redirection throughout this thread to narrow the audience to only "the
@template ecosystem".
I would vote "no" on this RFC as-is; it is too niche. It claims it is not niche
with "200k files" using @template, on github, focused on some of the important
frameworks for PHP, but not all of them. 200k files is a drop in the bucket
when you've worked on php repos spanning millions of files. It doesn't address
ALL php developers and from my example above, seems to be actively harmful to
new developers.
— Rob
