Re: [RFC] [Discussion] Bound-Erased Generic Types

Hi Rowan, The parts this RFC enforces (generic declaration syntax, type-parameter resolution, inheritance arity, bound conformance, parametric LSP, variance soundness, and turbofish arity) are exactly where static analysis tools currently disagree most. For evidence that these inconsistencies are real, you can look at the issue trackers for Mago, PHPStan, or Psalm. Even basic syntax varies across tools today: some use @template T of X while others use @template T as X. Defaults and inference are also major categories of disagreement. For example, new Collection([1]) could be inferred as several different types (Collection<1>, Collection<int>, Collection<scalar>, Collection<mixed>, Collection<numeric>); as a maintainer, there isn't always a "correct" answer. Native syntax like new Collection::<int>([1]) makes user intent explicit, forcing tools to converge on the same answer. The disagreement isn't limited to edge cases or inference. Even fundamental correctness questions divide the tools. Consider this diamond pattern: ```php /** @template T */ interface Example { /** @param T $v @return T */ public function produce(mixed $v): mixed; } /** @extends Example<A> */ interface AExample extends Example {} /** @extends Example<B> */ interface BExample extends Example {} class X implements AExample, BExample { /** @param A|B $v @return A */ #[Override] public function produce(mixed $v): A { /* ... */ } } ``` The correct return type here is A & B. The implementer must satisfy both AExample::produce(A): A and BExample::produce(B): B, which forces the parameter to be A | B (LSP widening on contravariant position) and the return to be A & B (LSP narrowing on covariant position to the intersection). Anything narrower violates one parent contract: returning just A breaks the BExample contract; returning just B breaks the AExample contract. Mago and PHPStan both accept A and B as return types: both are wrong. Psalm rejects A but accepts B: also wrong, and inconsistently so. Three tools exhibit three different incorrect behaviors on the same pattern. Under this RFC, the diamond-merge rule rejects both at compile time and forces the implementer to declare A & B, which is the only sound choice. - https://mago.carthage.software/1.27.1/en/playground/#019e32b2-a082-7482-7ad2-8ecc0f29e120 - https://phpstan.org/r/5044aa92-c599-45a3-ad24-c735db44a125 - https://psalm.dev/r/cf5d2dadd9 If the tool authors haven't independently converged on the correct answer, "agree on a conformance spec" isn't the lightweight coordination it sounds like. The disagreement isn't on edge cases; it's on what the *correct* answer is, and the people running the tools are the ones in the best position to know. ref: - https://github.com/carthage-software/mago/issues/899 (Mago recently added default support; Psalm still lacks this) - https://github.com/carthage-software/mago/issues/1859 (Mago disagreeing with Psalm and PHPStan; solved if we could have `->where::<int>($c, $o, $v)` and not rely on inference) - https://github.com/phpstan/phpstan/issues/12978 (solved with explicit turbofish) - https://github.com/vimeo/psalm/issues/7496 (RFC makes it clear that intersection works with generics if the bound is object or more specific) - https://github.com/vimeo/psalm/issues/5910 (fixed with explicit turbofish) If I went all day trying to find issues solved by this RFC, or inconsistencies between tools, this thread wouldn't end. For the parts the RFC doesn't enforce, such as flow analysis and type narrowing, tools will continue to handle them differently. However, native syntax narrows the surface of disagreement. Tools will start from the same parsed structure and expectations, rather than diverging early on what a docblock like @template T = mixed even means. Internals is not becoming a standards body for unenforced parts; tools will continue to compete on inference and narrowing quality by design. Regarding your suggestion to include all unchecked type information in one place: adding a syntactic tier that PHP parses but ignores would be a new architectural pattern. Beyond that, it creates its own coordination problem. If ~~lowercase-string is parsed by PHP but interpreted by tools, any disagreement on semantics (e.g., whether "" is lowercase, whether the rule is ASCII or multibyte, whether numeric strings count) remains. PHP would host syntax it doesn't understand, and the ecosystem would still lack a governance mechanism for those semantics. making it truly 100% useless. On the visibility of type parameters like TNode: it's true they can look like concrete types at use sites. However, this is consistent with languages like Java, Rust, and TypeScript. Conventions like single uppercase letters or PascalCase (e.g. TKey, TNode) are already well-established in the PHP ecosystem through @template. Native syntax promotes these established signals into the language. Cheers, Seifeddine.