> > > I'd like to put a syntax proposal on the table that may address Rowan's > concern, and that also addresses something I'm worried about independently: > the migration path for existing libraries. > > How does a library that uses @template docblocks today migrate to native > syntax without forcing a BC break on its consumers? Multiplied across the > libraries out there, this is a major point of tension for the ecosystem we > need to anticipate. > Existing @template annotations were adoptable gradually *because* they're > invisible to the engine. > Native <T> syntax, as the RFC proposes it, doesn't have that property: a > library cannot adopt it without bumping its minimum PHP version and pulling > all its consumers with it. > > We've solved this exact problem once before for attributes. The #[...] > syntax was deliberately designed so older PHP versions would parse it as a > # line comment, which is what made the adoption across the ecosystem so > smooth. > The same trick is available for generics if we pick the right delimiter. > Concretely, write #<...> everywhere <...> appears in the current RFC: > declarations, inheritance clauses, type uses in signatures, call-site > arguments. One syntax, used uniformly. > > Three benefits, beyond the migration story: > > 1. FC for free. A library can adopt native generics in source today and > continue running on older PHP versions, because the engine just sees > comments. No need to coordinate with the min-PHP bump. > 2. The turbofish goes away. No need to disambiguate < from less-than > comparison. With #<...>, the token is unique and unambiguous everywhere: at > declaration, use, and call site. We get to drop a whole grammar mechanism > rather than introduce one. > 3. Rowan's concern is addressed typographically. Anything inside #<...> is > the erased, SA-enforced layer; everything outside follows the engine's > normal runtime-checked rules. > > For codebases that want to adopt native generics while still supporting > earlier PHP versions, #<...> would need to sit at the end of a line so > older parsers consume it as a # line comment. Code targeting only > generics-aware PHP can write it inline. The line-break constraint is a > transitional code-style cost, not a permanent property of the syntax, and > it's bounded by however long libraries support pre-generics versions. > > WDYT? I expect Seifeddine has good reasons to prefer the current syntax. > I'd like to put this on the table because the FC story it unlocks, combined > with the turbofish simplification, might be worth the trade-off and might > help gather a broader consensus. > > Cheers, > Nicolas >
Nicolas, I think this is a brilliant idea. I was thinking that libraries would take ages to adopt this new syntax if they didn’t want to break compatibility with existing PHP versions, and your proposal solves this issue in a great way. The price to pay is slightly uglier syntax, but we already went through that with attributes. I think that initially we all thought the attribute syntax was quite terrible, but nowadays no one bats an eye at it. Cheers, Carlos
