Would it though? I’ve been thinking about this for a while.
What about introducing a new file extension for this? Something like MyClass.p so that .php is for classic syntax and .p Can support newer syntax? You could support old codebases while at the same time support better syntax.
It’s probably too much for the core php team to maintain both though
>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching
Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).
When you consider this, it’s amazing that we get so much from so little.
Your second option was rejected years ago I believe. The pipes were designed to work alongside this rfc that was supposed to be in this new version (8.5) but due to time constraints it had to be delayed and it’s currently being voted https://wiki.php.net/rfc/partial_function_application_v2
> just about everyone knows how to navigate in vscode by now.
I don’t know and honestly I hate the assumption of the software industry that everyone knows or uses vs code. I stuck to sublime for years until I made the switch to Jetbrains IDEs earlier this year.
I quickly looked up the market share and VS code seems to have about 70% which is a lot but the 30% that don’t use it is not that small of a number either.
Like I get it it’s very popular but it’s far from the only editor/IDE people use.