On 07/10/2022 16:44, Larry Garfield wrote:
Would they have been marked experimental at all? Why? What might have changed and when while in experimental phase? When would they have been removed instead of being adjusted? Etc.
That's an interesting thought experiment. Here are the thoughts that occur to me:
Some candidates to consider could be: 1. Named args
Possibly an experimental phase would have given more time for the names of arguments on internal functions to be decided. Some third-party libraries might also have taken advantage of that timescale, although some would still have decided to simply say names are not guaranteed to be stable.
2. Pipes 3. PFA
If experimental features had a lower voting threshold, perhaps these would have been accepted at that stage; but I'm not sure what would happen during that phase that would prevent them being rejected as a permanent feature.
4. Intersection types
Anything that leads to complex changes in the engine can realistically only be released in an annual .0 release, because the alpha & beta period is essential to spot regressions to existing functionality. That means an experimental flag will only ever mean waiting longer to use such features in production, not getting them sooner.
The only benefit would therefore be if there are behaviour details that are "locked in" which could have been changed if they were marked experimental; I'm not aware of any in this case, but it does happen - the discussions around readonly classes and inheritance come close, although allowing something that was previously forbidden at compile-time is generally not considered a BC break anyway.
6. JIT
This is already behind a run-time flag, and exposes very little direct API, so an "experimental" release would mostly be a question of documentation (on php.net, and in the shipped sample ini files), and the compiled-in default for the flag. That wouldn't have needed any new policy.
7. FFI
This *does* include a user-facing API, and that API has a few rough edges. However, it was developed entirely as an extension, and we already have a mechanism for marking those experimental: ship them in PECL first, and allow breaking changes while bundling into the main source tree. This happened with ext/sodium for instance. Why it didn't happen with FFI, I'm not entirely sure.
The same *might* go for Fibers, although delivery as an extension would probably require a different implementation from what we have. I'm not sure it would have made sense to ship it in a state that made changes to the engine, requiring changes to other extensions to be compatible, but then make users wait before using it in production.
Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
