Thank you all for participating in this discussion! Regarding the experimental features "disappearing" in a release, therefore, its use is not reliable, in reality the idea is that this is the exception of the exception (when, for example, the feature itself proves to be extremely unfeasible for performance or generating irreparable security flaws). It is not something as if every new idea becomes an experimental feature, but rather, ideas that already had a good technical discussion and the doubt was in the practical application itself, but with a great intention of turning it native in the language, however, making it available before time for refinement and common usage.
Regarding the code development, following the previous statement, the idea is that the core developers work on these modifications as well, since the idea of experimental features is for the code to become a native part of PHP. It's different from extensions, where the discussion is on the way to rejection and the developer who suggested it intends to do something practical aside, and eventually the PHP team decides to make it native (but that's another discussion, and I believe it's already possible at the moment, at least part of the idea). A more practical example is the following: In the PHP RFC we have several proposals already accepted, often before the vote, we already have a good idea of their acceptance. But let's pay attention to only those votes that have already been approved. Normally these features are only applied in the next version, PHP 8.2, however, when it is released, it may lack some refinements in this sense. Let's take, for example, the RFC "allow null and false as stand-alone types". This feature was voted and passed unanimously on 2022-03-27, but PHP 8.2 is due for 2022-11-24 (as far as I know -- aka Google tells me). However, it is a feature already developed and could very well be available on an experimental basis, so we have time to test it on smaller or personal projects, for example, until PHP 8.2 is available where this functionality will be 100% refined and ready to use. declare (experimental_allow_null_false_standalone_type = 1); Another advantage in this sense is that it would be possible to have a single development branch for PHP 8.1 (current version) and 8.2 (development version), for example, with the difference of some definitions in the code that activate or deactivate the experimental features already developed for the future version. So a new intended feature can be developed in 8.1 code and marked as experimental (and common users will be able to try them out, using them in an experimentally explicit way), and when you start preparing for the 8.2 release, those definitions become final. Another advantage is that a new feature can be "delayed" to a future-future version (eg. 8.3) if it is believed not to be refined enough for the next version's release. All I want to say is: I would love to be able to use new PHP features ahead of time in personal projects, without having to wait for new versions to be released (and in the meantime, I would be able to give feedback). Just as I'm willing to take the risk of failure, after all, these are experimental features and shouldn't be used in production (unless you're willing to take risks). The difference between using the in-development version of PHP 8.2 is that many servers only make this version officially available after a few months, while smaller versions of PHP usually become available within a few days. Atenciosamente, David Rodrigues Em qua., 5 de out. de 2022 às 13:02, Christian Schneider < cschn...@cschneid.com> escreveu: > Am 05.10.2022 um 15:38 schrieb Alex Wells <autau...@gmail.com>: > > Advantages of experimental features over extensions: > > - they allow changes to the parser > > - they are universally supported (by IDE's, parsers etc) because they are > > part of a stable language release, not an unpopular/unknown extension > > - usages of them can be found in a codebase and then analysed (unlike > > extensions that don't have any kind of marker to denote them from regular > > code) > > - it's easy to implement a universal warning mechanism - for IDEs, static > > analysers and PHP itself to warn users about the consequences of using an > > experimental feature > > - they don't need a versioning mechanism, because they are effectively > > always "alpha" - i.e. non-stable, so any PHP release can introduce a > > breaking change into an experimental feature > > Just to maybe have a more complete picture, here are some possible > advantages of extensions over experimental features; > - Core developers don't have to support/maintain it (they already have a > lot on their plate) > - Extensions have the notion of alpha/beta/stable releases and they can > offer different versions at the same time. > - Having to install them manually makes it obvious that you are on your > own if you use them in production but the notion of a stable extension is > an indication that it is not completely reckless :-) > > The fact that you explicitly list always being alpha as an advantage for > experimental features makes me wonder when I would actually use them: > - Certainly not in production? Which limits the amount of exposure such a > feature gets to real world usage, therefore limiting the amount of insight > in the usefulness too. > - A branch for a future version of your code? But the experimental feature > could disappear anytime again, do you want to rely on the feature at some > point becoming standard? > > My $.02, > - Chris > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
