On Fri, Oct 7, 2022, at 5:58 AM, G. P. B. wrote: > On Fri, 7 Oct 2022 at 07:57, Christian Schneider <cschn...@cschneid.com> > wrote: > >> But now to my main point: You are talking about the most simple and >> isolated case, a new function. >> > > I agree, and for most intent and purposes a function can be polyfilled in > userland. So this is the least interesting case. > > However, I don't think this approach is that useful. To give an example, > for DNF types the implementation is based on a change in how iterable works > in PHP. > It went from a pseudo-type to a compile time alias, as this massively > simplified variance and LSP checks. > I would not want such a change to land in a patch release especially as it > turned out there was an unintended BC break with the compile time > redundancy which only got fixed in PHP8.2RC2. > > >> 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. >> > > Ditto. > > When Nikita proposes editions back in 2020 ( > https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md) > the point about them was mainly about backwards-incompatible changes, > not > new features. > Because in general new features don't have the same issues, especially > since the RFC process (although not without its issues) does force > thinking > about the design of it instead of just shoving something in php-src > randomly as in the before days. > > Best regards, > > George P. Banyard
I think what would be useful here to better understand the value, if any, would be to look back at some recent RFCs, both those that passed and those that didn't, and imagine how they would have gone had there been an "experimental" flag option for them. 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. Some candidates to consider could be: 1. Named args 2. PIpes 3. PFA 4. Intersection types 5. Enums 6. JIT 7. FFI Personally I'm still highly skeptical that this would be useful, or useful enough to justify the engine complexity. Bear in mind that browsers had "experimental" CSS features for a while, and eventually abandoned prefixing as it was an absolute mess as the experimental features ended up in production and then had to be supported forever in that early, broken form. Instead, they switched to an opt-in flag in browser configuration (~php.ini setting) on the assumption that devs could play with it, but *it was completely impractical to ship to production* so no one did, so they could still change it. Experimental features never leave the dev's own computer until they are no longer experimental. That has worked out a lot better. We should learn from that experience. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
