Hi, These all are valid concerns! I cannot speak about management and cost issues though, as I am not an active PHP dev team member.
> 3. What's the MVP? How do we measure usefulness, adoption and maintenance > complexity? As a shot in the dark, the first step could be implementation of typed lists in my opinion. Do not implement full-blown static analyser nor the type checker for each possible case, just only check the usage of typed lists within the pre-processed files. Assume that whatever comes from the non-preprocessed ones is correct. Make only simple naive assumptions for all internal array_ functions as well as basic array operations. If there is some runtime magic going on with constructing the list, just fallback to infering the type as a simple array. For such cases, allow a special attribute which will tell the type checker this variable / property etc will indeed contain the typed list, like a @var annotation for IDEs / static analysers nowadays. The preprocessor / type checker **should not aim to 100% guarantee the correct types will be in the runtime**: TypeScript does this neither. Rowan has mentioned Dart language in a parallel thread, which makes most of the checks statically, but for some cases the compiler still adds runtime checks. Rowan warned that PHP might have a lot of such cases possible though. But I still think this also might be a good idea for MVP. > 4. Is it an aborttable idea? If things go south and can't be supported > anymore, how bad for PHP adopters would it be? I don't think any of PHP new features that go live are abortable. This affects not only my suggestion, but also everything what has been done for PHP in past. Once a feature is in the language and released to the public, you cannot revert it. There must be a long multi-year process preceded with a deprecation at least. A concept of experimental features was suggested earlier, but this is completely different topic, so I believe we should not go into that rabbit hole here. Overall, I consider this question orthogonal (or irrelevant if you prefer) to the original topic, let's take as an axiom that there is no way back. > 5. How would voting on the spec be like? Complete years-work-hours spec or > small incremental functionalities? Small incremental functionalities. Gradually more stuff could be proven statically, more complex cases covered, and while they are not, an attribute / static assertion could be used. Maybe some of such assertions could be allowed to be preserved in runtime, at the cost of some performance penalty, IDK. But I believe we should leave such choice to developers, whether they want the checks in runtime as well. > 6. Is versioning tightly coupled with PHP version or does it have its own > version support system targeting multiple php versions at the same time? I strongly believe it must go hand in hand with the PHP version, and not as a separate tool, because I see it as a feature of a PHP language itself. > Overall, I think PHP has been constantly losing popularity in favor of > Typescript and a transpiler could create an exciting solution for some of > PHP's problems, but it does not seem like a pet project. Sure, it should be considered seriously and requires some upfront planning. Though, well, PHP itself started as a pet project :D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
