The idea is that the experimental features are exclusively something that the PHP team has voted for (approved) and that will be part of the language.
Users can choose to install PECL, but it is not the same, because it depends on other users (who can make use of this code) having the notion that a certain PECL will be necessary. Imagine a package under development (eg. Laravel 10) that is (supposing that) intended to be released compatible with PHP 8.3 (supposing that it already has experimental features). In this case, the Laravel team can start using an experimental feature while developing Laravel 10, waiting for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel 10 can just remove the experimental tags and release its new version fastly. The user, on condition that he is willing to use Laravel 10 (in development) will make indirect use of experimental features. Then both the Laravel team and these users will be able to provide feedback for these features to the PHP team before the official release. Like json_validate(): assuming Laravel needs to check if a code is valid JSON, but without processing its data for use. It could check if PHP >= 8.3, so use experimental_json_validate(), else use previous PHP compatible code. Atenciosamente, David Rodrigues Em seg., 10 de out. de 2022 às 19:20, David Gebler <davidgeb...@gmail.com> escreveu: > My two cents... > > Why can't "common users" install a PECL extension? It's not a difficult, > obscure or undocumented process. > > I can accept the reasoning > > > Apply a PECL strategy to try experimental features might not be the > convenient way always, for example, if we create a new ... sensitive ini > setting that affects the behavior of PHP somehow... OR ... what about a new > sensitive funtion in a "core extension" like JSON? > > But why would the answer in those cases not be "compile the PHP > fork/branch with the experimental feature", rather than find a way to flag > the engine to switch arbitrary new features on or off, complete with all > the complications in the primary source code that would cause? We are, > after all, talking about features which by definition should not be relied > upon for any production use. > > Or we're talking about features which are stable and valuable enough to > have passed an RFC process, but then what's gained from an experimental > designation? Why couldn't they just be included in a preview/beta/RC > version which anyone could decide to run or not? >
