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

On 11 May 2026 22:17:22 BST, Seifeddine Gmati <azjezz@carthage.software> wrote:

The principle: as long as we don't change the semantics of existing syntax, no future improvement introduces a BC break. Reified generics, for example, can be added later as opt-in, just like how HackLang did it (https://docs.hhvm.com/hack/reified-generics/reified-generics-migration/). A class or function would need to declare #[ReifiedGenerics] (or similar) to opt into reified semantics; everything else continues to behave exactly as the bound-erased model specifies. Library and framework authors then choose the strictness-vs-performance tradeoff that fits their use case, and existing code never breaks because the default behavior never changes.

This feels like a cop-out to me. Imagine we had done the same for visibility keywords: "private" was a reserved word, but the engine didn't enforce it, it was just there for static analysers; then later, we added an opt-in attribute #[EnforceVisibility]. Either everyone would use it and whinge about it not being the default; or nobody would use it, and whinge about the language having a broken visibility system. Or imagine if we implemented scalar type declarations, but couldn't decide whether to make them fully-static or auto-coercing, so we implemented a switch that had to be set at the call-site, and was widely misunderstood ... oh, wait, we did that one...

The existing SA tools (PHPStan, Psalm, Mago) aren't just type checkers. Type checking is part of what they do, but they also handle a much larger surface: types PHP itself has no notion of (positive-int, non-empty-lowercase-string, class-string<Foo>, list{1, 3, "hello"}, and 100s more, see https://carthage-software.github.io/suffete/universe/elements.html), plus code quality rules, security analysis, dead code detection, and so on. A first-party tool would need to compete on that whole surface to be useful, anything narrower would disappoint the audience that actually wants SA.

I think it's possible to separate "people who want static analysis" from "people who want the type system to be efficiently enforced". And it would be perfectly reasonable to maintain separate tools for those separate audiences. Take Java, for instance: every Java compiler will automatically complain about basic type violations; but there are still plenty of third-party Java static analysis tools. I don't think that indicates a flaw in the compiler design; it's just different tools for different audiences. In the same way, a bundled tool that statically enforced generic types *and nothing else* would still have value - particularly if it was somehow mandatory, like a pre-processing step. -- Rowan Tommins [IMSoP]