Re: Experimental features

> On 11 Oct 2022, at 15:24, Christian Schneider <cschneid@cschneid.com> wrote: > > We seem to have two different views on experimental feature here: You are saying they could get > removed again while others stated it is for stuff which will definitely end up in stable when the > next major release is done. An experimental feature definitely might (although highly unlikely) get removed again - that's part of the idea that a feature can change, evolve or downright be cancelled. But I think the point was to say that experimental features still have to undergo a full RFC process (possibly with a lower voting threshold) and are generally expected to be stabilized somewhere in the next few major/minor releases. The stabilization may take a while - there are some components of Kotlin which are still experimental since the 1.0 release (2016), but most of the features are stabilized in a span of two releases. Overall the idea of experimental features is allow PHP maintainers to make mistakes, thus lowering the requirements for feature's refinement and try it on real users in real world projects instead of attempting to think every possible little detail through when creating an RFC, most of the time having zero analytics/statistics. Decisions needs to be made based on data if possible instead of premature conclusions, and experimental features aim to allow just that. > On 11 Oct 2022, at 15:24, Christian Schneider <cschneid@cschneid.com> wrote: > > That's another thing where we need to find an agreement first: Are we talking new, > isolated functions or are we possibly also talking about core new language features (i.e. new syntax > / semantics)? > > The work for maintenance by core developers could be much higher if it is not limited to new > functions. > This is IMHO an important aspect as we do not want to make life even harder for the core team. > > Hot take: If it is only about new functions then we don't need anything in the core, just > create an \Experimental package with poyfills and you're done ;-) Both. Experimental features certainly do apply to new syntax & semantics too. It would have definitely been very useful for past RFCs - short closures, sealed classes, useland operators, pipe operator etc. Regarding the polyfills, how is this gonna work? Say a new feature gets introduced and then it's arguments order changes, what a polyfill is gonna do here? > On 11 Oct 2022, at 15:24, Christian Schneider <cschneid@cschneid.com> wrote: > > ... but almost all of them can. > > I'd go as far as saying that while emulating json_validate() using json_decode() is > slower and uses more memory it still is a valid polyfill. It is IMHO easy enough to develop with a > higher memory limit and performance is not that critical for development either. > > And unless you want to ship experimental code to production (which you shouldn't) you will > have to wait for the next major PHP release anyway. Generally, the "experimental" part of the feature only applies to the syntax/semantics/spec, not to the actual implementation. This means that there's no reason to avoid shipping experimental code to production - you might need to change it in the future, but it doesn't mean it's just going to suddenly break out of nowhere. Runtime stability is expected to be on par with the stability of "regular" features.