> On 12 Oct 2022, at 11:06, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > If a "preview" doesn't allow us to make breaking changes, then what exactly > is the point? I don't see any benefit at all to this without that. > > If the "preview" is *actually* just "put out an RFC in the next patch > release as soon as it's merged to master", which is what it seems you're > saying (as that seems like all that's left with all the things you said we > can't do in a preview), then that seems dubious, prone to instability in > the engine outside of the preview features, and a total breakage of the > release cycle and RM process that is currently in place.
100% agree. Kotlin's experimental features are drastically different from what was described by David. I don't think "feature previews" deliver any value to PHP's development process here; mainly, it doesn't allow breaking changes, thus not allowing developers to be at ease when accepting features due to knowing they could make changes as they go, which I see as the main benefit. It would have helped deliver features which were otherwise declined due to someone not liking the syntax, not seeing the usefulness or just not convinced. If a feature is proven to not be a good fit for PHP then it's removed. Feature previews as I see it solve exactly one problem: feature's runtime stability - but I don't think this is a problem of PHP in the first place.
