On 12.5.2026 00:07:19, Rowan Tommins [IMSoP] wrote:
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...
I totally agree that an attribute meaningfully altering runtime
behaviour (unlike the current ones which are mostly simple checks) is
bonkers.
If we ever switch to reified generics (i.e. particularly on runtime
values), we need to seriously enforce it. Everywhere.
This is - yes - a BC break. But should only be a break for code which
does already forbidden things. We can document very clearly that
non-enforcement is not an excuse for not following the type checks. And
just switch. We could also opt for having a deprecation phase where
mismatching types are allowed, but emit E_DEPRECATED. Maybe with an INI
(to be removed a couple versions later). At least library code is
generally to much higher standards than application code anyway.
Not sure if it's the best way, but surely solutions can be found.
I don't know if this is necessarily a blocker. It's not optimal, but
maybe okay.
Bob
