On Wed, 3 Jun 2026 at 18:49, Matthew Brown <[email protected]> wrote:
> > > On Tue, 2 Jun 2026 at 11:15, Gina P. Banyard <[email protected]> wrote: > >> As you already know from off list discussion I will vote against this RFC. >> I've laid my arguments in a blog post on my website. [1] >> >> The only thing I take offence to is saying my attempt/proposal has >> stalled. >> Me not actively working on it 24/7 doesn't mean it stalled, and I had >> started working on it earlier in the year before this RFC landed, or I was >> aware you were working on something. >> >> Best regards, >> >> Gina P. Banyard >> >> [1] https://gpb.moe/blog/opinion-bound-erased-generics.html > > Also: the article also dedicates a long section to the potential for transpilers. I believe a transpiler would fail to gain ground for a few reasons: - The parser would need to keep up with the upstream parser, like nikic/php-parser does - But it could not share the same source code as nikic/php-parser — it would need to be a fork, as the code would no longer be PHP - To provide accurate error positions, static analysis tools would need to support the "enhanced" ASTs directly (which would mean they could no longer use nikic/php-parser) - Source maps. Source maps everywhere. And then there's the trust issue which you reference in your article. Trust is *incredibly* important when developers choose to migrate all their source code to a new system. Microsoft's TypeScript has earned that trust over the course of a decade with incredible tooling that has cost that company tens of millions of dollars to produce and market. That effort is not trivial to reproduce, nor would the vast majority of PHP repos likely deem it worthwhile. OTOH if this proposal is accepted everyone those same audiences get generics without any effort on their part. I believe that's why there is strong community support for this proposal.
