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
