I wanted to suggest the possibility of introducing experimental features to PHP.
This is an old thread I guess, but I think it's good to reevaluate the situation from time to time, as other languages already do this to some extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and libraries (React) bring features natively in an experimental way. I wanted to propose that we bring this idea into PHP, so we wouldn't have to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out these new features, and so when these versions arrive, they'll already be quite polished, avoiding patches sometime later due to wider usage of users. My idea is to have two levels of experimental features: (1) Via declare(), when the feature affects how PHP can act when reading the file itself. Eg. declare(experimental_operator_override = true), Something that happens with Kotlin, for example, when we use some experimental annotations like contracts. These declarations work "per file", so whenever it is necessary to use it, it must be declared. (2) Via experimental identifier name. Eg. experimental_json_validate() or Experimental::json_validate(), like in Kotlin and also in React. Experimental features can only be brought into a minor version (eg. PHP 8.1.12) when it is minimally refined and practically ready to use. It would be "kind of" an expected final version, no new patches are expected (we hope), unless something really went unnoticed. Despite this, experimental features may not exist until the next major/minor release if its practical inefficiency is found or if the concept is shown to be invalid. So it should always be a "use with care". However, if an experimental feature is successful, it becomes final at the next major/minor or major/minor+1. The experimental version becomes an alias during some future versions until it is removed entirely. This is the time for users to adapt their code and for IDEs to help us find them. With this, we can understand whether users are making use of a certain feature or not, make improvements on it, etc. I notice that many good features are rejected because they are believed to be bad for PHP or can be confusing, but without any practical testing. Experimental features can make this analysis more grounded in practical data than just possibilities. However, this also doesn't mean that any idea can become an experimental feature, but ideas that have a good foundation and a good discussion before it. The difference is that the feature can be tested in practice before being totally rejected, and approved features can be delivered ahead of time to refine before the next version is released, allowing users to try them out more easily. Atenciosamente, David Rodrigues
