Re: [RFC] [Discussion] Bound-Erased Generic Types

Hi Seifeddine, Thank you so much for making and pushing for this RFC. As the current maintainer of Psalm, I fully support the overall design of the RFC, and I especially support the choice of erased generics, considering the current state of the PHP ecosystem and of php-src itself. Choosing erased generics has two major benefits: - Acknowledging and building upon the currently existing rich ecosystem of static analysers, without significantly changing/breaking existing generic semantics already used by the ecosystem and by the community. - Not locking down semantics for PHP itself by letting future RFCs and implementations do the (very) heavy lifting of runtime validation, using for example monomorphized generics, or i.e. with a static analyzer API, to plug existing static analyzers directly into PHP itself (one of the more promising approaches in my opinion, creating a true TypePHP without rewriting yet another static analyser from scratch, re-using existing, tested and working tools). I will implement support for this RFC in Psalm immediately after the RFC is approved (fingers crossed). I have just a few minor notes after briefly skimming the RFC and the discussion (absolute non-blockers, just a bit of bikeshedding :) 1) Turbofish at callsite: this was already brought up before, while I understand the precedence issues that led to this choice, having written some rust myself, I *still* don’t like the syntax, and would very much prefer normal diamond syntax at callsite, like for declarations. Without diving too deeply into the parser, it seems to me that enabling plain diamond syntax should be easy-ish at least with class instantiation using new, even though some of the worst offenders when it comes to readability aren’t class instantiations but rather static calls: ``` [self::foo::<Bar>(1), self::foo::<Bar>(2)] // :( ``` 2) -/+ for variant bounds: also brought up before, while it *can* be somewhat mnemonic (- consumes for input params, + produces for output params), in/out would indeed be much more descriptive IMO (or at the very least, both options could be provided at the same time). 3) More of a wording issue, the RFC describes the new reflection API as the primary way to consume generics, but the main consumers (static analysers) will consume them using nikic/php-parser (as usual, unless another RFC is made to bring proper AST-based parsing infrastructure into PHP itself :), with the new reflection generic API being used only for native/extension generic APIs. Kind regards, Daniil Gentili — Daniil Gentili - Senior software artisan Portfolio: https://daniil.it <https://daniil.it/> Telegram: https://t.me/danogentili