 As a #PHP library author, I don't see the value in erased types or erased generic type declarations, especially since we already have PHPStan, Psalm, and Phan, the type systems of which are effectively erased at runtime. If you want erased types, use those tools. When I use those tools to build a library, and others use my library without using those tools or an IDE that uses them, then all type guarantees are off the table. I don't see how erased types will improve this situation. 11 comments
@cabbey If I'm not mistaken, Python and Java both use erased types, and TypeScript is pretty much quintessential erased types. It's something being considered for PHP, too: https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections/ @ramsey @cabbey TypeScript (in the browser, for now) can only be executed after transpiling to JS. Consumers of a TS library need transpiling to use it directly or as a dependency, and types are checked at transpilation time. Psalm/PHPStan don't require consumers to run them before using/requiring library code. They're dev tools, that's it. A PHP file format that would need transpiling before being consumed by the engine, and do type check at that transpiling time would be useful. @ramsey @cabbey It would be really great if transpiling would be self-hosted. Imagine you require a library via Composer. When pulling the code, Composer recognizes it needs transpiling, so it does it and puts the transpiled code in the vendor folder. If transpiling fails, Composer installation fails. This is not the same of Psalm/PHPStan, even if you could achieve something similar with a Composer plugin that requires the tool and run it on installation. @ramsey @cabbey That hypothetical plugin could run the SA tool when the corresponding configuration file is found. But we have several SA tools, and they don't have the same format for comments/attributes. Nor they have the same funcionalities. Something officially defined by the PHP project would allow Composer to implement this check-then-erase flow on installation, ensuring anyone using a lib would need to go through the static analysis step. @ramsey @cabbey TS libs shared transpiled is not TS fault. For PHP, my point is that erased types could be useful if they would be only usable in a different format that would require "check + erasure" before being consumed by the engine. People could still distribuite "already erased" version of their code, but that's on them. Those who distribuite the non-erased version would force consumers to do that step. And if Composer could do it on install, that would require no change on devs workflow @ramsey @cabbey Imagine the scenario. There's a new .phps format that allows advanced types, generics, etc. The engine can *not* consume it. Composer recognizes it and do erasure (the engine provides means to do it). If composer.json requires a library that "provides" types checks, Composer will use that library to check the code before erasure. This would have no impact on people who do not want to type-check, but would empower a lot people who want to use advanced types, etc. |
Gregory's Server
@ramsey this is the first I’ve heard of “erased types”. If the name is accurate, I already don’t like the concept. Will have to look into it to confirm.