Hi Bob, > I totally agree that an attribute meaningfully altering runtime > behaviour (unlike the current ones which are mostly simple checks) is > bonkers.
The "attribute changing runtime behavior is bonkers" concern is fair, and the principle of opt-in doesn't require the attribute spelling specifically. A keyword (class A<reified T>), or a separate declaration form all carry the same semantic without putting runtime-altering metadata in the attribute system. The spelling is open. > We could also opt for having a deprecation phase where > mismatching types are allowed, but emit E_DEPRECATED. That path could be under consideration, but I think the opt-in path is structurally better, for two reasons beyond BC. First, reification isn't free even when it's correct. The library author who SA-verifies their generic types and ships clean code pays a runtime cost for the application developer who didn't run SA. Universal reification transfers cost from sloppy code to careful code, which is the wrong direction. Second, the Hack designers had this exact choice (their codebase is internal, they could have flipped semantics on themselves) and chose opt-in. They went erased-by-default with reify as an opt-in keyword (https://docs.hhvm.com/hack/reified-generics/reified-generics/). The reason is the same cost-transfer concern: most generic code at Facebook or Slack scale is type-safe via SA, and forcing it to incur reification costs would slow the whole codebase for the benefit of a small percentage of code that genuinely needs runtime checking. All that said: I appreciate you flagging this isn't a blocker. The opt-in path is what I think the right design is; if reified generics ever ship, the spelling debate happens in that RFC, not this one Cheers, Seifeddine.
