On 11 May 2026 22:17:22 BST, Seifeddine Gmati <[email protected]> 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]

Reply via email to