Am 06.10.2022 um 23:40 schrieb David Rodrigues <david.pro...@gmail.com>: > But keep in mind that these features are already intended for PHP, and it > is not a "feature test" or suggestion. The voting process is mandatory and > the feature must already be set to "accepted".
Just so I understand what you are saying: You would only add things to experimental where an RFC for it has been accepted? What you basically want to do is to introduce such features into the current stable branch instead of the upcoming one, right? > However, we need to separate an experimental feature into stages, much like > Node does, so these are my suggestions: [...] > 2. Open experimental: the feature has already been state internally by > "adventurous users" and can already be used without php.ini configurations, > however, its use in code still needs experimental markers (eg. > experimental_json_validate() or declare(experimental_*)). BC is unlikely to > happen unless the feature has issues that need to be resolved before an > official release. Removing the feature is suggested not to happen, with the > exception of very serious and irreparable issues. One side-note here: I would strongly advise not to use an experimental_ prefix or package for functions because it would be a PITA to make code compatible with different versions, one where the function has the experimental_ prefix / package and one where it doesn't. But now to my main point: You are talking about the most simple and isolated case, a new function. Your model may work fine with that but as soon as we are talking something like a syntax change we have some additional problems: - Enabling it with a prefix obviously does not work, something like declare() is definitely needed - Maintaining such changes to the engine / parser could turn out messy, e.g. lots of "if (experimental_x)"-like code in the core - The test suite would possibly have to deal with an exponential explosion of experimental feature combinations to make sure they don't interfere with each other. All in all I'm not sold yet that the benefit outweighs the cost of this approach. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
