Am 11.10.2022 um 07:09 schrieb MKS Archive <m...@newclarity.net>: >> On Oct 10, 2022, at 8:04 PM, David Gebler <davidgeb...@gmail.com> wrote: >> >> This is what's bothering me. Either these "experimental" features have >> passed RFC and will be part of the language, as you've said above, or >> they're actually experimental i.e. not finalized and implementing behaviour >> and syntax which may be subject to change or even dropped entirely >> depending on the feedback cycle. > > If they are not experimental and their usage is finalized, then they are > in-fact approved and they would be absolutely no different from the existing > RFCs today. > > You cannot have experimental features unless those features have the > potential to not be included in the future language and/or those features > have the potential to be improved before they are finalized. Otherwise, > what's the point?
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. IMHO there needs to be a consensus about this before we can continue the discussion, otherwise we will go around in circles. >> Using the trivial json_validate() example (although as others have said, a >> simple new function is probably a bad example), > > (As an aside, I disagree that a new function would be a bad example. I think > it would be a good use-case for experimental features because of how > decoupled it would be from the rest of the language, and it would help to see > if a lot of people use the function before committing to including it.) 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 ;-) >> If it's the former, the library can just check if PHP >= 8.3 and fall back >> to userland implementation / polyfill for earlier versions. This is just >> what we have now, where approved new features are part of a versioned >> release. > > Not all potentially useful functions can reasonably be implemented in > userland PHP. ... 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. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
