Re: [PHP-DEV] Experimental features

[juan carlos morales]

I am back into PHP internals.

After reading again and again, I would like to say that I think we
should keep the release process as it is. If there is a feature not
currently available in the current release,  *at least* a user has
the possibility to download and compile the code  by itself; not the
best practice but ... for sure ... consistent and possible.

I think we should keep the release process as it is, until a real
scenario shows up, that would make us think about experimental
features.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Mike Schinkel]

> On Oct 11, 2022, at 8:24 AM, Christian Schneider  
> 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.
> 
> IMHO there needs to be a consensus about this before we can continue the 
> discussion, otherwise we will go around in circles.

True. In my view experimental would allow to features to be tried that might 
get removed, but others may not want that.

However, I think it is really a moot point because of RFC voting. If enough 
people felt it might get removed they would vote against it. And if after 
something was experimental if enough people felt it should be removed they 
would vote to do so.

So each individual RFC as well as voting addresses that concern.

> 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.

Again, each individual RFC and voting address that concern. 

If an experimental RFC would resolve it "too much" maintenance by core 
developers then it would get voted down. A 2/3rd bar for success is not a low 
bar, especially in a community with so many divergent opinions. 

> 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 
> ;-)

My hot take: Having the entire PHP community made aware of a given experimental 
function — including all the blog posts that would be written about it — is != 
to an individual developer creating an \Experimental namespace and writing 
their own blog post about it. 

>> Not all potentially useful functions can reasonably be implemented in 
>> userland PHP.
> 
> ... but almost all of them can.

See reply in prior paragraph.

> 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.

For json_validate() people have *already* been using a polyfill, and it was 
found sorely lacking for memory-use reasons.  So a reason for making it 
experimental would be to see if the proposed signature was sufficient for 
mainstream needs.

Oh, and a higher memory limit is not always a viable solution.

> 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.

Not all "production" code is equal. My blog != Wikipedia, for example.

-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Alex Wells]

> On 11 Oct 2022, at 15:24, Christian Schneider  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  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  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.

Re: [PHP-DEV] Experimental features

[Christian Schneider]

Am 11.10.2022 um 07:09 schrieb MKS Archive :
>> On Oct 10, 2022, at 8:04 PM, David Gebler  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

Re: [PHP-DEV] Experimental features

[Rowan Tommins]

Hi all,

I'm still not convinced everyone on this thread is actually talking 
about the same idea.


For instance, on whether an experimental feature would require the same 
consensus as a non-experimental one:



On 11/10/2022 00:06, Mike Schinkel wrote:

If there were an RFC for Experimental Use then the people on the fence could choose to 
allow it to see how it plays out in real-world userland cases, and a few people against 
it might be convinced to allow people to evaluate it, and then later make a decision on a 
"Forever RFC."


On 11/10/2022 05:38, Jordan LeDoux wrote:

I don't really see what the confusion is about. It's for features that we
have all agreed to include, but that the public API or behavior might
change in minor versions while usage information, feedback, and so-on
happens.



Similarly, some are talking about getting features to users sooner, but 
others about leaving it experimental for as long as it takes, which 
means it gets to production *later* than if it was tested in the 
existing alpha/beta cycle.



I think it would be really helpful to have some concrete examples, 
either from other languages, or of a hypothetical feature that you think 
would be a good use case clarifying:


* How it would be accepted as experimental - would it require the same 
voting threshold etc as a "stable" feature?
* When would it be released - in PHP terms, if it was voted on in April 
this year, would it have gone into 8.1.5 or waited until 8.2.0?
* What is the process for changes? Would they require votes? Would they 
go into point releases like 8.1.9 or 8.2.5, or wait until 8.3.0?
* What is the process for marking stable? Would it require another vote? 
What version would *that* go into?



I'm not saying we have to have final answers to these questions, but it 
would be helpful to understand people's gut feeling on them, to get a 
better idea of what people are imagining.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[MKS Archive]

> On Oct 10, 2022, at 8:04 PM, David Gebler  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?

BTW, I googled several different phrases trying to find a horror story in 
Node.js because of their experimental features, but the only thing I was able 
to find was people glowing about the features that are currently experimental 
and/or the excitement when a feature graduated to fully supported, for example:

https://nodesource.com/blog/experimental-features-in-node.js/

Maybe you can find examples of downsides of having experimental features in 
Node.js (or some other language/platform) that I was unable to find? If so, it 
would be instructive to learn from their experiences.

> 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.)

> 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.

> If it's the latter, everyone touching the experimental version, directly or
> indirectly, may have to rip out and change code later which renders the
> work they've put in to use the experimental feature in their code pointless.

That is not a hard software engineering problem. Software developers have been 
isolating 3rd party dependencies for decades. There's no reason why developer 
could not isolate (most) potential experimental features in the same way.

> I'm inclined to suggest if you opt in to an experimental language feature,
> you are by definition making at least an implicit declaration that you know
> what you're doing,

You speak of people "knowing what they are doing" as if it were a binary thing, 
i.e. they know what they are doing or they do not. Let me use an analogy for 
you here to try to make the counter point.

There are a handful of doctors of the world's leading heart surgeons.  They 
absolutely "know what they are doing."  But if I have brain cancer and need a 
tumor excised, I would not let any one of those doctors touch me unless they 
were also celebrated as a brain surgeon. I am guessing you would feel the same.

Similarly, someone can be an excellent software developer but not have strong 
DevOps or sysadmin skills. In my 10+ years working with PHP I met, knew, and 
worked with *many* people like that. And for many years, *I* was one of those 
people.

> so the idea people using these features wouldn't have
> the skills to spin up a container or install something on a VM doesn't
> convince me, personally.

Not every developer is a polymath. Some are excellent at writing software but 
cannot configure a server or a VM or Docker container to save their life.  In 
my LinkedIn I could probably give you a list of 100 developers what that would 
apply to.  

IOW, they are a lot of excellent heart surgeons out there but they just don't 
know how to fix a brain.

-Mike

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Jordan LeDoux]

On Mon, Oct 10, 2022 at 5:05 PM David Gebler  wrote:

> On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues 
> wrote:
>
> > The idea is that the experimental features are exclusively something that
> > the PHP team has voted for (approved) and that will be part of the
> language.
> >
>
> So they're not experimental features, they're accepted RFCs, maybe with a
> lower voting threshold.
>
>
I don't really see what the confusion is about. It's for features that we
have all agreed to include, but that the public API or behavior might
change in minor versions while usage information, feedback, and so-on
happens. The idea behind an experimental inclusion would be something like
"the concept behind this feature we've agreed to include, unless something
truly drastic comes up once it's out in the wild, but the syntax,
parameters, and signatures might change while we look at usage and
real-world code.

It's like the opposite of a Deprecation notice in my mind... it's a flag on
specific code that lets people know *ahead of time* that BC breaks in a
minor version might be necessary for this feature for a little while.

Jordan

Re: [PHP-DEV] Experimental features

[David Gebler]

On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues 
wrote:

> The idea is that the experimental features are exclusively something that
> the PHP team has voted for (approved) and that will be part of the language.
>

So they're not experimental features, they're accepted RFCs, maybe with a
lower voting threshold.


> Imagine a package under development (eg. Laravel 10) that is (supposing
> that) intended to be released compatible with PHP 8.3 (supposing that it
> already has experimental features). In this case, the Laravel team can
> start using an experimental feature while developing Laravel 10, waiting
> for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel
> 10 can just remove the experimental tags and release its new version fastly.
>
> The user, on condition that he is willing to use Laravel 10 (in
> development) will make indirect use of experimental features. Then both the
> Laravel team and these users will be able to provide feedback for these
> features to the PHP team before the official release.
>
> Like json_validate(): assuming Laravel needs to check if a code is valid
> JSON, but without processing its data for use. It could check if PHP >=
> 8.3, so use experimental_json_validate(), else use previous PHP compatible
> code.
>

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. In which case, they cannot be relied on by
developers of vendor packages or their users in the manner you suggest.

Using the trivial json_validate() example (although as others have said, a
simple new function is probably a bad example), either this function will
be part of PHP 8.3, with the exact behaviour, parameters and return type
which is known and documented, or it's experimental and might change.

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.

If it's the latter, everyone touching the experimental version, directly or
indirectly, may have to rip out and change code later which renders the
work they've put in to use the experimental feature in their code pointless.

And it's not just how these things may or may not be used by users of the
language, it's how building out this system affects the clarity and
maintainability of php-src, which is esoteric enough as it is.

I can appreciate and support specific individual new, accepted features
which may not be 100% stable having a toggle in the configuration, but I'm
not convinced on the justification for a broader system of introducing
unstable features which are toggled at the syntax level.

On Tue, Oct 11, 2022 at 12:06 AM Mike Schinkel  wrote:

> A lot of developers (most?) who build PHP applications run them in
> shared-hosted or managed hosted servers where are never given the option to
> install a PECL extension.

In the rare cases they can install PECL many of those PHP developers would
> not have the skills to do it or the requisite permissions on the server; I
> certainly did not for the first ~10 years of working with PHP. I do now,
> but ironically because I have mostly moved away from programming in PHP to
> do more DevOps work.
>

> Further, when working in multiple environments having to set up each
> server to have all the same PECL installations can be just too much hurdle
> so that developers won't even try, especially when working in managed
> environments.
>
>
I'm inclined to suggest if you opt in to an experimental language feature,
you are by definition making at least an implicit declaration that you know
what you're doing, so the idea people using these features wouldn't have
the skills to spin up a container or install something on a VM doesn't
convince me, personally.

Re: [PHP-DEV] Experimental features

[Mike Schinkel]

> On Oct 10, 2022, at 6:20 PM, David Gebler  wrote:
> 
> My two cents...
> 
> Why can't "common users" install a PECL extension? It's not a difficult,
> obscure or undocumented process.

A lot of developers (most?) who build PHP applications run them in 
shared-hosted or managed hosted servers where are never given the option to 
install a PECL extension. 

In the rare cases they can install PECL many of those PHP developers would not 
have the skills to do it or the requisite permissions on the server; I 
certainly did not for the first ~10 years of working with PHP. I do now, but 
ironically because I have mostly moved away from programming in PHP to do more 
DevOps work.

Further, when working in multiple environments having to set up each server to 
have all the same PECL installations can be just too much hurdle so that 
developers won't even try, especially when working in managed environments.

[1] https://stackoverflow.com/a/12750694/102699


> I can accept the reasoning
> 
>> Apply a PECL strategy to try experimental features might not be the
> convenient way always, for example, if we create a new ... sensitive ini
> setting that affects the behavior of PHP somehow... OR ... what about a new
> sensitive funtion in a "core extension" like JSON?
> 
> But why would the answer in those cases not be "compile the PHP fork/branch
> with the experimental feature", rather than find a way to flag the engine
> to switch arbitrary new features on or off, complete with all the
> complications in the primary source code that would cause? We are, after
> all, talking about features which by definition should not be relied upon
> for any production use.
> 
> Or we're talking about features which are stable and valuable enough to
> have passed an RFC process, but then what's gained from an experimental
> designation? Why couldn't they just be included in a preview/beta/RC
> version which anyone could decide to run or not?

It does not seem reasonable that the bar to include a feature as experimental 
should be the same bar as currently exists for forever features.  Opinions 
expressed on the list typically fall into one of three categories:  

1.) Please, please yes! 
2.) No way whatsoever! or 
3.) I am not convinced...

Generally it seems that unless 2/3rd are in the #1 category an RFC fails to 
pass, even if after evaluating in the wild the people in group #3 might come to 
see a lot of value in it and some in #2 might even change their mind. In those 
cases PHP suffers. 

If there were an RFC for Experimental Use then the people on the fence could 
choose to allow it to see how it plays out in real-world userland cases, and a 
few people against it might be convinced to allow people to evaluate it, and 
then later make a decision on a "Forever RFC."

---

Also, the comments along the lines of "Well, this could quickly get out of 
hand" presume that the people voting for experimental use won't take that into 
consideration and vote against things if it seems like things are in-fact 
getting out of hand. But they will take that into consideration just a as the 
take other concerns into consideration now, and thus only the better ideas will 
be likely to make it through to experimental status.

---

One more thing on this topic. PHP could ALSO allow experimental features to be 
written in PHP, and ship those experimental features with PHP so that code 
would always be available, at least when experimental features are turned on, 
and without having to include said code.  

The benefit there would be people could more quickly implement an experimental 
feature to see how it might work in the wild before going to all the effort to 
implement in C in PHP's core code, for things that can be implemented in PHP.

-Mike

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[David Rodrigues]

The idea is that the experimental features are exclusively something that
the PHP team has voted for (approved) and that will be part of the language.

Users can choose to install PECL, but it is not the same, because it
depends on other users (who can make use of this code) having the notion
that a certain PECL will be necessary.

Imagine a package under development (eg. Laravel 10) that is (supposing
that) intended to be released compatible with PHP 8.3 (supposing that it
already has experimental features). In this case, the Laravel team can
start using an experimental feature while developing Laravel 10, waiting
for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel
10 can just remove the experimental tags and release its new version fastly.

The user, on condition that he is willing to use Laravel 10 (in
development) will make indirect use of experimental features. Then both the
Laravel team and these users will be able to provide feedback for these
features to the PHP team before the official release.

Like json_validate(): assuming Laravel needs to check if a code is valid
JSON, but without processing its data for use. It could check if PHP >=
8.3, so use experimental_json_validate(), else use previous PHP compatible
code.


Atenciosamente,
David Rodrigues


Em seg., 10 de out. de 2022 às 19:20, David Gebler 
escreveu:

> My two cents...
>
> Why can't "common users" install a PECL extension? It's not a difficult,
> obscure or undocumented process.
>
> I can accept the reasoning
>
> > Apply a PECL strategy to try experimental features might not be the
> convenient way always, for example, if we create a new ... sensitive ini
> setting that affects the behavior of PHP somehow... OR ... what about a new
> sensitive funtion in a "core extension" like JSON?
>
> But why would the answer in those cases not be "compile the PHP
> fork/branch with the experimental feature", rather than find a way to flag
> the engine to switch arbitrary new features on or off, complete with all
> the complications in the primary source code that would cause? We are,
> after all, talking about features which by definition should not be relied
> upon for any production use.
>
> Or we're talking about features which are stable and valuable enough to
> have passed an RFC process, but then what's gained from an experimental
> designation? Why couldn't they just be included in a preview/beta/RC
> version which anyone could decide to run or not?
>

Re: [PHP-DEV] Experimental features

[David Gebler]

My two cents...

Why can't "common users" install a PECL extension? It's not a difficult,
obscure or undocumented process.

I can accept the reasoning

> Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive ini
setting that affects the behavior of PHP somehow... OR ... what about a new
sensitive funtion in a "core extension" like JSON?

But why would the answer in those cases not be "compile the PHP fork/branch
with the experimental feature", rather than find a way to flag the engine
to switch arbitrary new features on or off, complete with all the
complications in the primary source code that would cause? We are, after
all, talking about features which by definition should not be relied upon
for any production use.

Or we're talking about features which are stable and valuable enough to
have passed an RFC process, but then what's gained from an experimental
designation? Why couldn't they just be included in a preview/beta/RC
version which anyone could decide to run or not?

Re: [PHP-DEV] Experimental features

[Rowan Tommins]

On 07/10/2022 16:44, Larry Garfield wrote:

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.



That's an interesting thought experiment. Here are the thoughts that 
occur to me:




Some candidates to consider could be:

1. Named args



Possibly an experimental phase would have given more time for the names 
of arguments on internal functions to be decided. Some third-party 
libraries might also have taken advantage of that timescale, although 
some would still have decided to simply say names are not guaranteed to 
be stable.




2. Pipes
3. PFA



If experimental features had a lower voting threshold, perhaps these 
would have been accepted at that stage; but I'm not sure what would 
happen during that phase that would prevent them being rejected as a 
permanent feature.




4. Intersection types



Anything that leads to complex changes in the engine can realistically 
only be released in an annual .0 release, because the alpha & beta 
period is essential to spot regressions to existing functionality. That 
means an experimental flag will only ever mean waiting longer to use 
such features in production, not getting them sooner.


The only benefit would therefore be if there are behaviour details that 
are "locked in" which could have been changed if they were marked 
experimental; I'm not aware of any in this case, but it does happen - 
the discussions around readonly classes and inheritance come close, 
although allowing something that was previously forbidden at 
compile-time is generally not considered a BC break anyway.




6. JIT



This is already behind a run-time flag, and exposes very little direct 
API, so an "experimental" release would mostly be a question of 
documentation (on php.net, and in the shipped sample ini files), and the 
compiled-in default for the flag. That wouldn't have needed any new policy.




7. FFI



This *does* include a user-facing API, and that API has a few rough 
edges. However, it was developed entirely as an extension, and we 
already have a mechanism for marking those experimental: ship them in 
PECL first, and allow breaking changes while bundling into the main 
source tree. This happened with ext/sodium for instance. Why it didn't 
happen with FFI, I'm not entirely sure.


The same *might* go for Fibers, although delivery as an extension would 
probably require a different implementation from what we have. I'm not 
sure it would have made sense to ship it in a state that made changes to 
the engine, requiring changes to other extensions to be compatible, but 
then make users wait before using it in production.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Alex Wells]

> On 7 Oct 2022, at 18:44, Larry Garfield  wrote:
> 
> On Fri, Oct 7, 2022, at 5:58 AM, G. P. B. wrote:
>> On Fri, 7 Oct 2022 at 07:57, Christian Schneider 
>> 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/-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
> 

I don't think it's valid to compare browser (client side) and PHP (server 
side): browser versions and support is not controlled by the server, so it's 
not fair to expect client-side experimental features to perform as good as 
server-side ones. If there's anyone to learn from, it should be Kotlin or other 
server languages.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Larry Garfield]

On Fri, Oct 7, 2022, at 5:58 AM, G. P. B. wrote:
> On Fri, 7 Oct 2022 at 07:57, Christian Schneider 
> 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/-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

Re: [PHP-DEV] Experimental features

[G. P. B.]

On Fri, 7 Oct 2022 at 07:57, Christian Schneider 
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/-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

Re: [PHP-DEV] Experimental features

[Christian Schneider]

Am 06.10.2022 um 23:40 schrieb David Rodrigues :
> But keep in mind that these features are already intended for PHP, and it
> is not a "feature test" or suggestion. The voting process is mandatory and
> the feature must already be set to "accepted".

Just so I understand what you are saying: You would only add things to 
experimental where an RFC for it has been accepted?
What you basically want to do is to introduce such features into the current 
stable branch instead of the upcoming one, right?

> However, we need to separate an experimental feature into stages, much like
> Node does, so these are my suggestions:

[...]

> 2. Open experimental: the feature has already been state internally by
> "adventurous users" and can already be used without php.ini configurations,
> however, its use in code still needs experimental markers (eg.
> experimental_json_validate() or declare(experimental_*)). BC is unlikely to
> happen unless the feature has issues that need to be resolved before an
> official release. Removing the feature is suggested not to happen, with the
> exception of very serious and irreparable issues.

One side-note here: I would strongly advise not to use an experimental_ prefix 
or package for functions because it would be a PITA to make code compatible 
with different versions, one where the function has the experimental_ prefix / 
package and one where it doesn't.

But now to my main point: You are talking about the most simple and isolated 
case, a new function.
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.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[David Rodrigues]

> If I start coding an application that relies on these new types, is there
a chance that they'll be removed completely, and I have to rewrite it all?

Imagine that there are users, like me, who would like to test features in
development (mainly in order to provide feedback to the development team).
It shouldn't be something a user should use for big productions, but maybe
for smaller personal projects.

This is an opportunity to make improvements to the feature for the next
release, without the risk of having to do so during it.

But keep in mind that these features are already intended for PHP, and it
is not a "feature test" or suggestion. The voting process is mandatory and
the feature must already be set to "accepted".

However, we need to separate an experimental feature into stages, much like
Node does, so these are my suggestions:

1. Closed experimental: the feature has successfully passed the approval
phase, including an available PR. However, the feature will only be
available through additional configuration in php.ini, as it can still
undergo BC changes, including its complete removal.

2. Open experimental: the feature has already been state internally by
"adventurous users" and can already be used without php.ini configurations,
however, its use in code still needs experimental markers (eg.
experimental_json_validate() or declare(experimental_*)). BC is unlikely to
happen unless the feature has issues that need to be resolved before an
official release. Removing the feature is suggested not to happen, with the
exception of very serious and irreparable issues.

3. Stable: the feature proves stable enough to be used "as is" in an
official version, but is still kept as an experimental marker until a new
official version is released. At this point, imagine that it is as if the
resource were indeed official, so it would no longer be possible to remove
it or make BC changes.

4. Available: the feature is now an official part of the language and can
be used in a major/minor version without the experimental markers. Markers
will continue to work until the next major update as an alias.

Also, if a user tries to use experimental features without being aware of
it (eg. did not activate it in php.ini or did not use declare()), an error
message should be displayed.

It also makes me rethink the time it takes for a feature to be ready to be
officially delivered. My suggestion would be at least 3 months for the 1st
and another 3 months for the 2nd stage. While the "stable" stage would last
as long as needed for the next major/minor release.

This generates less risk for new features and earlier feedback from users
willing to test it.

Atenciosamente,
David Rodrigues


Em qui., 6 de out. de 2022 às 17:12, Rowan Tommins 
escreveu:

> On 06/10/2022 17:41, Alex Wells wrote:
> > For example, Kotlin has recently introduced a new feature - unsigned
> integer types.
>
>
> I'm still struggling to understand what I, as a user, would do about this.
>
> If I start coding an application that relies on these new types, is
> there a chance that they'll be removed completely, and I have to rewrite
> it all? Is there a chance that every minor version I upgrade might
> introduce subtle changes in the behaviour of my code? Or is there just a
> chance that someone will decide the bikeshed's the wrong colour and I
> have to regex replace all my "123u" to say "u123" instead?
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Experimental features

[Jordan LeDoux]

On Thu, Oct 6, 2022 at 1:12 PM Rowan Tommins 
wrote:

> On 06/10/2022 17:41, Alex Wells wrote:
> > For example, Kotlin has recently introduced a new feature - unsigned
> integer types.
>
>
> I'm still struggling to understand what I, as a user, would do about this.
>
> If I start coding an application that relies on these new types, is
> there a chance that they'll be removed completely, and I have to rewrite
> it all? Is there a chance that every minor version I upgrade might
> introduce subtle changes in the behaviour of my code? Or is there just a
> chance that someone will decide the bikeshed's the wrong colour and I
> have to regex replace all my "123u" to say "u123" instead?
>
>
I would think all of the above, though I would expect given the nature of
the RFC process that it would be exceedingly rare in PHP. It would be like
a release preview only in a stable version. It does seem like it would have
utility in PHP, since we could introduce a feature without worrying about
BC breaks if it needs to be modified and adjusted.

Jordan

Re: [PHP-DEV] Experimental features

[Alex Wells]

> On 6 Oct 2022, at 23:12, Rowan Tommins  wrote:
> 
> On 06/10/2022 17:41, Alex Wells wrote:
>> For example, Kotlin has recently introduced a new feature - unsigned integer 
>> types.
> 
> 
> I'm still struggling to understand what I, as a user, would do about this.
> 
> If I start coding an application that relies on these new types, is there a 
> chance that they'll be removed completely, and I have to rewrite it all? Is 
> there a chance that every minor version I upgrade might introduce subtle 
> changes in the behaviour of my code? Or is there just a chance that someone 
> will decide the bikeshed's the wrong colour and I have to regex replace all 
> my "123u" to say "u123" instead?
> 
> 
> Regards,
> 
> -- 
> Rowan Tommins
> [IMSoP]
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Yes to all. There's a chance for anything to happen with an experimental 
feature any time. 

This of course doesn't mean it has to happen; actually, it barely ever happens. 
It's not like Kotlin ships features without thinking them through - it's just 
that they have that fallback to introduce a breaking change without any 
additional hassles (like deprecations or keeping a backwards-compatibility 
promise) if they want it.

Allowing breaking changes in patch releases in Kotlin does sound reasonable - 
at the very least most breaking changes will get caught on compilation stage. 

This won't happen with PHP, so we're likely better off still limiting any 
breaking changes to minor/major releases. Yet we're still winning in a sense 
that there won't be any deprecations needed (which not only saves a lot of 
time, but also simplifies the process a lot) and will have a safe window to 
change the API altogether when problems arise. 

You as a user act as an alpha-tester of language's feature, with all the 
related pros and cons. You get access to all the newest and shiniest, but you 
have to always keep track of PHP's changelog (much more than "regular" users) 
and be prepared to act upon breaking changes (again, possibly a lot more than 
regular users).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Rowan Tommins]

On 06/10/2022 17:41, Alex Wells wrote:

For example, Kotlin has recently introduced a new feature - unsigned integer 
types.



I'm still struggling to understand what I, as a user, would do about this.

If I start coding an application that relies on these new types, is 
there a chance that they'll be removed completely, and I have to rewrite 
it all? Is there a chance that every minor version I upgrade might 
introduce subtle changes in the behaviour of my code? Or is there just a 
chance that someone will decide the bikeshed's the wrong colour and I 
have to regex replace all my "123u" to say "u123" instead?



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Alex Wells]

> On 6 Oct 2022, at 16:06, Rowan Tommins  wrote:
> 
> On 06/10/2022 12:16, Alex Wells wrote:
>> A marker merely just tells the compiler "hey, allow me to use this feature 
>> right here", i.e. it denotes a piece of code as allowed to use the feature, 
>> not enable it. Effectively, all experimental features are just regular 
>> features that are "always on" and hence can be optimized the same way 
>> regular features are. The marker serves two purposes: allow simple discovery 
>> of usages (by the compiler or other tools) and force the developer to 
>> acknowledge they're using an experimental feature with an unstable 
>> API/syntax/spec.
> 
> 
> I don't really understand the distinction between "enabling" and "being able 
> to use", nor what it would mean for a feature to "experimental" but also 
> integrated fully into the language.
> 
> In general, I'm finding it quite hard to follow the idea in the abstract - 
> the definition of "feature" seems very fuzzy. Could someone give some 
> examples from another language, or concrete examples where it would be used 
> in PHP, and then work through the details of what would be expected to happen 
> in what version of PHP?
> 
> 
>> Regarding the monitoring - that is a problem that needs to be solved and 
>> there are multiple solutions: GitHub issues, corporate/public messengers 
>> (Slack?) or the internals mailing list.
> 
> 
> There are certainly ways to approach it; I'm just agreeing with a previous 
> commenter that this would need to be an explicit part of any proposal, not 
> just hand-waved away.
> 
> Regards,
> 
> -- 
> Rowan Tommins
> [IMSoP]
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

I'll try my best to elaborate, although I the author of the proposal will 
likely do a better job.

A feature is generally considered any addition to the language or it's standard 
library - that could be a new set of functions, new syntax etc. Experimental 
features refer to features whose stability is "experimental".

Kotlin divides their features into four stability levels: experimental, alpha, 
beta and stable. Each of those might have their own preconditions, BC promises 
and release cycle rules. A feature with "experimental" stability level requires 
an opt-in: a piece of code that uses the new feature must be marked with an 
annotation. For example, Kotlin has recently introduced a new feature - 
unsigned integer types. This inlcudes new types and a new syntax. This is how 
you'd use them:

```kotlin
@OptIn(ExperimentalUnsignedTypes::class)
fun unsignedInt(): UInt {
return 123u
}

@OptIn(ExperimentalUnsignedTypes::class)
fun main(args: Array) {
println(
unsignedInt()
)
}
```

`123u` here denotes an integer that is unsigned. The `u` part is the new 
syntax. `UInt` is the new type. Notice two `OptIn` annotations - one for the 
function which returns the new type, and the other for it's dependent. The 
second annotation is needed because of the return type - Kotlin assumes the 
return type is used, effectively assuming you're using the new type in your 
function, which requires opt-in.

This changes if `unsignedInt` returns `Int` (a regular type, not part of the 
experimental feature) instead:

```kotlin
@OptIn(ExperimentalUnsignedTypes::class)
fun unsignedInt(): Int {
return 123u as Int // cast UInt to Int
}

fun main(args: Array) {
println(
unsignedInt()
)
}
```

Notice how an opt-in is no longer needed for `main`.

If you omit the opt-in altogether, this is what the compiler (and the IDE) will 
throw at you:  `Main.kt: (7, 20): This declaration is experimental and its 
usage should be marked with '@kotlin.ExperimentalUnsignedTypes' or 
'@OptIn(kotlin.ExperimentalUnsignedTypes::class)'`

Of course, in Kotlin there also mechanism to opt-in more than just a single 
function. This can be done on file, module or even project level:
```
@file:OptIn(ExperimentalUnsignedTypes::class)
// or module-wide
sourceSets {
someModule {
languageSettings.optIn("org.mylibrary.OptInAnnotation")
}
}
// or project-wide compiler flag
-opt-in=org.mylibrary.OptInAnnotation
```



Onto the PHP application. It's similar, although obviously due to the dynamic 
nature of the language the compiler wouldn't be able to force opt-ins nearly on 
the same level as Kotlin compiler does. This isn't to say experimental features 
can't be implemented properly in PHP.

Let's say PHP wants to experiment with a new function - `json_validate()`. The 
idea is simple: follow the regular RFC process and release the function the 
same way you would without experimental functions. The only thing that is 
needed is to mark the function as one that requires an opt-in:

```php
#[Experimental(ExperimentalLevel.WARNING)]
class ExperimentalJsonValidate {}

#[RequiresOptIn(ExperimentalJsonValidate::class)]
function json_validate($something): something {}
```

Then, any 

Re: [PHP-DEV] Experimental features

[Rowan Tommins]

On 06/10/2022 12:16, Alex Wells wrote:

A marker merely just tells the compiler "hey, allow me to use this feature right here", 
i.e. it denotes a piece of code as allowed to use the feature, not enable it. Effectively, all 
experimental features are just regular features that are "always on" and hence can be 
optimized the same way regular features are. The marker serves two purposes: allow simple discovery 
of usages (by the compiler or other tools) and force the developer to acknowledge they're using an 
experimental feature with an unstable API/syntax/spec.



I don't really understand the distinction between "enabling" and "being 
able to use", nor what it would mean for a feature to "experimental" but 
also integrated fully into the language.


In general, I'm finding it quite hard to follow the idea in the abstract 
- the definition of "feature" seems very fuzzy. Could someone give some 
examples from another language, or concrete examples where it would be 
used in PHP, and then work through the details of what would be expected 
to happen in what version of PHP?




Regarding the monitoring - that is a problem that needs to be solved and there 
are multiple solutions: GitHub issues, corporate/public messengers (Slack?) or 
the internals mailing list.



There are certainly ways to approach it; I'm just agreeing with a 
previous commenter that this would need to be an explicit part of any 
proposal, not just hand-waved away.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Alex Wells]

> On 6 Oct 2022, at 15:26, Christoph M. Becker  wrote:
> 
> On 04.10.2022 at 22:42, David Rodrigues wrote:
> 
>> I wanted to suggest the possibility of introducing experimental features to
>> PHP.
>> 
>> This is an old thread I guess, but I think it's good to reevaluate the
>> situation from time to time, as other languages already do this to some
>> extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
>> libraries (React) bring features natively in an experimental way.
>> 
>> I wanted to propose that we bring this idea into PHP, so we wouldn't have
>> to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out these
>> new features, and so when these versions arrive, they'll already be quite
>> polished, avoiding patches sometime later due to wider usage of users.
> 
> Do the other platforms introduce experimental features in revisions?  I
> doubt that, and I'm pretty sure that is (at least currently) no option
> for PHP.  We have several months of bi-weekly pre-releases for new
> minor/major versions, and are barely able to stabilize new features; not
> only wrt. to the feature itself, but also wrt. unforeseen side effects.
> 
> The current release cycle[1] still mostly makes sense to me, and that
> says for revisions:
> 
> * Bugfixes only (with a room for exceptions on a case by case basis and
> only for small self contained features additions)
> 
> I wouldn't want to sacrifice stability in favor of shipping new features
> every month – including having more discussions about which feature may
> be introduced in a revision.
> 
> [1] 
> 
> --
> Christoph M. Becker
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Speaking of Kotlin, there are no rules regarding experimental features. This is 
because they extensively use their "opt-in" API, which allows them to mark even 
a single function/method as experimental. It doesn't make sense to wait a minor 
release for a year to introduce a single new function.

Of course, any medium-large size features are kept to minor/major releases.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Alex Wells]

> On 5 Oct 2022, at 20:41, Rowan Tommins  wrote:
> 
> On Wed, 5 Oct 2022 at 18:07, David Rodrigues  wrote:
> 
>> Another advantage in this sense is that it would be possible to have a
>> single development branch for PHP 8.1 (current version) and 8.2
>> (development version), for example, with the difference of some definitions
>> in the code that activate or deactivate the experimental features already
>> developed for the future version.
>> 
> 
> 
> The problem I predict with this is that unless they have a convenient "hook
> point", experimental features would lead to ugly code: they need to be
> enabled at run-time rather than build-time, so are hard to optimise; and
> they are going to be released after a short test cycle, so need to avoid
> refactoring.
> 
> Maybe there are enough "hook points" in the engine that some categories of
> feature could be implemented without too much disruption, but it's a
> complex beast with a shortage of experts, so I'm wary of adding more
> complexity.
> 
> I also agree with the previous comment that this would need to be coupled
> with some way of monitoring the results - imagine we released an
> experimental feature 3 months ago, what do we do exactly to find out if it
> needs changing?
> 
> Regards,
> -- 
> Rowan Tommins
> [IMSoP]

A marker merely just tells the compiler "hey, allow me to use this feature 
right here", i.e. it denotes a piece of code as allowed to use the feature, not 
enable it. Effectively, all experimental features are just regular features 
that are "always on" and hence can be optimized the same way regular features 
are. The marker serves two purposes: allow simple discovery of usages (by the 
compiler or other tools) and force the developer to acknowledge they're using 
an experimental feature with an unstable API/syntax/spec. 

Regarding the monitoring - that is a problem that needs to be solved and there 
are multiple solutions: GitHub issues, corporate/public messengers (Slack?) or 
the internals mailing list.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Rowan Tommins]

On Wed, 5 Oct 2022 at 18:07, David Rodrigues  wrote:

> Another advantage in this sense is that it would be possible to have a
> single development branch for PHP 8.1 (current version) and 8.2
> (development version), for example, with the difference of some definitions
> in the code that activate or deactivate the experimental features already
> developed for the future version.
>


The problem I predict with this is that unless they have a convenient "hook
point", experimental features would lead to ugly code: they need to be
enabled at run-time rather than build-time, so are hard to optimise; and
they are going to be released after a short test cycle, so need to avoid
refactoring.

Maybe there are enough "hook points" in the engine that some categories of
feature could be implemented without too much disruption, but it's a
complex beast with a shortage of experts, so I'm wary of adding more
complexity.

I also agree with the previous comment that this would need to be coupled
with some way of monitoring the results - imagine we released an
experimental feature 3 months ago, what do we do exactly to find out if it
needs changing?

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Experimental features

[David Rodrigues]

Thank you all for participating in this discussion!

Regarding the experimental features "disappearing" in a release, therefore,
its use is not reliable, in reality the idea is that this is the exception
of the exception (when, for example, the feature itself proves to be
extremely unfeasible for performance or generating irreparable security
flaws). It is not something as if every new idea becomes an experimental
feature, but rather, ideas that already had a good technical discussion and
the doubt was in the practical application itself, but with a great
intention of turning it native in the language, however, making it
available before time for refinement and common usage.

Regarding the code development, following the previous statement, the idea
is that the core developers work on these modifications as well, since the
idea of experimental features is for the code to become a native part of
PHP.

It's different from extensions, where the discussion is on the way to
rejection and the developer who suggested it intends to do something
practical aside, and eventually the PHP team decides to make it native (but
that's another discussion, and I believe it's already possible at the
moment, at least part of the idea).

A more practical example is the following:

In the PHP RFC we have several proposals already accepted, often before the
vote, we already have a good idea of their acceptance. But let's pay
attention to only those votes that have already been approved. Normally
these features are only applied in the next version, PHP 8.2, however, when
it is released, it may lack some refinements in this sense.

Let's take, for example, the RFC "allow null and false as stand-alone
types". This feature was voted and passed unanimously on 2022-03-27, but
PHP 8.2 is due for 2022-11-24 (as far as I know -- aka Google tells me).
However, it is a feature already developed and could very well be available
on an experimental basis, so we have time to test it on smaller or personal
projects, for example, until PHP 8.2 is available where this functionality
will be 100% refined and ready to use.

declare (experimental_allow_null_false_standalone_type = 1);

Another advantage in this sense is that it would be possible to have a
single development branch for PHP 8.1 (current version) and 8.2
(development version), for example, with the difference of some definitions
in the code that activate or deactivate the experimental features already
developed for the future version.

So a new intended feature can be developed in 8.1 code and marked as
experimental (and common users will be able to try them out, using them in
an experimentally explicit way), and when you start preparing for the 8.2
release, those definitions become final.

Another advantage is that a new feature can be "delayed" to a future-future
version (eg. 8.3) if it is believed not to be refined enough for the next
version's release.

All I want to say is: I would love to be able to use new PHP features ahead
of time in personal projects, without having to wait for new versions to be
released (and in the meantime, I would be able to give feedback). Just as
I'm willing to take the risk of failure, after all, these are experimental
features and shouldn't be used in production (unless you're willing to take
risks). The difference between using the in-development version of PHP 8.2
is that many servers only make this version officially available after a
few months, while smaller versions of PHP usually become available within a
few days.


Atenciosamente,
David Rodrigues


Em qua., 5 de out. de 2022 às 13:02, Christian Schneider <
cschn...@cschneid.com> escreveu:

> Am 05.10.2022 um 15:38 schrieb Alex Wells :
> > Advantages of experimental features over extensions:
> > - they allow changes to the parser
> > - they are universally supported (by IDE's, parsers etc) because they are
> > part of a stable language release, not an unpopular/unknown extension
> > - usages of them can be found in a codebase and then analysed (unlike
> > extensions that don't have any kind of marker to denote them from regular
> > code)
> > - it's easy to implement a universal warning mechanism - for IDEs, static
> > analysers and PHP itself to warn users about the consequences of using an
> > experimental feature
> > - they don't need a versioning mechanism, because they are effectively
> > always "alpha" - i.e. non-stable, so any PHP release can introduce a
> > breaking change into an experimental feature
>
> Just to maybe have a more complete picture, here are some possible
> advantages of extensions over experimental features;
> - Core developers don't have to support/maintain it (they already have a
> lot on their plate)
> - Extensions have the notion of alpha/beta/stable releases and they can
> offer different versions at the same time.
> - Having to install them manually makes it obvious that you are on your
> own if you use them in production but the notion of a stable extension is
> 

Re: [PHP-DEV] Experimental features

[Christian Schneider]

Am 05.10.2022 um 15:38 schrieb Alex Wells :
> Advantages of experimental features over extensions:
> - they allow changes to the parser
> - they are universally supported (by IDE's, parsers etc) because they are
> part of a stable language release, not an unpopular/unknown extension
> - usages of them can be found in a codebase and then analysed (unlike
> extensions that don't have any kind of marker to denote them from regular
> code)
> - it's easy to implement a universal warning mechanism - for IDEs, static
> analysers and PHP itself to warn users about the consequences of using an
> experimental feature
> - they don't need a versioning mechanism, because they are effectively
> always "alpha" - i.e. non-stable, so any PHP release can introduce a
> breaking change into an experimental feature

Just to maybe have a more complete picture, here are some possible advantages 
of extensions over experimental features;
- Core developers don't have to support/maintain it (they already have a lot on 
their plate)
- Extensions have the notion of alpha/beta/stable releases and they can offer 
different versions at the same time.
- Having to install them manually makes it obvious that you are on your own if 
you use them in production but the notion of a stable extension is an 
indication that it is not completely reckless :-)

The fact that you explicitly list always being alpha as an advantage for 
experimental features makes me wonder when I would actually use them: 
- Certainly not in production? Which limits the amount of exposure such a 
feature gets to real world usage, therefore limiting the amount of insight in 
the usefulness too.
- A branch for a future version of your code? But the experimental feature 
could disappear anytime again, do you want to rely on the feature at some point 
becoming standard?

My $.02,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Alex Wells]

Hey.

Experimental features have been briefly discussed before in
https://github.com/PHPGenerics/php-generics-rfc/issues/49. I believe this
is a good starting point to understand how it's different to extensions or
otherwise different builds of PHP.

Advantages of experimental features over extensions:
 - they allow changes to the parser
 - they are universally supported (by IDE's, parsers etc) because they are
part of a stable language release, not an unpopular/unknown extension
 - usages of them can be found in a codebase and then analysed (unlike
extensions that don't have any kind of marker to denote them from regular
code)
 - it's easy to implement a universal warning mechanism - for IDEs, static
analysers and PHP itself to warn users about the consequences of using an
experimental feature
 - they don't need a versioning mechanism, because they are effectively
always "alpha" - i.e. non-stable, so any PHP release can introduce a
breaking change into an experimental feature

On Wed, Oct 5, 2022 at 1:38 AM Flávio Heleno 
wrote:

> On Tue, Oct 4, 2022, 17:43 David Rodrigues  wrote:
>
> > I wanted to suggest the possibility of introducing experimental features
> to
> > PHP.
> >
> > This is an old thread I guess, but I think it's good to reevaluate the
> > situation from time to time, as other languages already do this to some
> > extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
> > libraries (React) bring features natively in an experimental way.
> >
> > I wanted to propose that we bring this idea into PHP, so we wouldn't have
> > to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out
> these
> > new features, and so when these versions arrive, they'll already be quite
> > polished, avoiding patches sometime later due to wider usage of users.
> >
> > My idea is to have two levels of experimental features:
> >
> > (1) Via declare(), when the feature affects how PHP can act when reading
> > the file itself. Eg. declare(experimental_operator_override =
> > true), Something that happens with Kotlin, for example, when we use some
> > experimental annotations like contracts. These declarations work "per
> > file", so whenever it is necessary to use it, it must be declared.
> >
> > (2) Via experimental identifier name. Eg. experimental_json_validate() or
> > Experimental::json_validate(), like in Kotlin and also in React.
> >
> > Experimental features can only be brought into a minor version (eg. PHP
> > 8.1.12) when it is minimally refined and practically ready to use. It
> would
> > be "kind of" an expected final version, no new patches are expected (we
> > hope), unless something really went unnoticed.
> >
> > Despite this, experimental features may not exist until the next
> > major/minor release if its practical inefficiency is found or if the
> > concept is shown to be invalid. So it should always be a "use with care".
> >
> > However, if an experimental feature is successful, it becomes final at
> the
> > next major/minor or major/minor+1. The experimental version becomes an
> > alias during some future versions until it is removed entirely. This is
> the
> > time for users to adapt their code and for IDEs to help us find them.
> >
> > With this, we can understand whether users are making use of a certain
> > feature or not, make improvements on it, etc.
> >
> > I notice that many good features are rejected because they are believed
> to
> > be bad for PHP or can be confusing, but without any practical testing.
> > Experimental features can make this analysis more grounded in practical
> > data than just possibilities.
> >
> > However, this also doesn't mean that any idea can become an experimental
> > feature, but ideas that have a good foundation and a good discussion
> before
> > it. The difference is that the feature can be tested in practice before
> > being totally rejected, and approved features can be delivered ahead of
> > time to refine before the next version is released, allowing users to try
> > them out more easily.
> >
> >
> > Atenciosamente,
> > David Rodrigues
> >
>
> Hi David,
>
> Could this be done through extensions instead of having to develop a new
> process/support code?
>
> When json support was first introduced into php, it was done as an
> extension and then, after a while, incorporated into the core.
>

Re: [PHP-DEV] Experimental features

[Flávio Heleno]

On Wed, Oct 5, 2022 at 8:16 AM Deleu  wrote:

> On Wed, Oct 5, 2022, 7:54 AM juan carlos morales <
> dev.juan.mora...@gmail.com>
> wrote:
>
> >
> > Apply a PECL strategy to try experimental features might not be the
> > convenient way always, for example, if we create a new ... sensitive
> > ... ini setting that affects the behavior of PHP somehow, then ...
> > maybe applying the PECL strategy might not be the most confortable way
> > to approach it, OR ... what about a new sensitive funtion in a "core
> > extension" like JSON?
> >
>
> Just to build up on this. I feel like Extensions are maybe a technical /
> development feature that may have the power to address the issue, but from
> a "Product" (PHP language as the product) this isn't the best. Anything
> behind extensions add a significant entry burden and reduce the reach for
> users of the product, be it for lack of trust, knowledge or lack of
> infrastructure that allows such changes.
>
> >
>

Deleu & Juan,

Thanks for clearing this up!

A product approach could be something interesting to explore. I'm more than
happy to join and help anyway I can.

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] Experimental features

[Deleu]

On Wed, Oct 5, 2022, 7:54 AM juan carlos morales 
wrote:

>
> Apply a PECL strategy to try experimental features might not be the
> convenient way always, for example, if we create a new ... sensitive
> ... ini setting that affects the behavior of PHP somehow, then ...
> maybe applying the PECL strategy might not be the most confortable way
> to approach it, OR ... what about a new sensitive funtion in a "core
> extension" like JSON?
>

Just to build up on this. I feel like Extensions are maybe a technical /
development feature that may have the power to address the issue, but from
a "Product" (PHP language as the product) this isn't the best. Anything
behind extensions add a significant entry burden and reduce the reach for
users of the product, be it for lack of trust, knowledge or lack of
infrastructure that allows such changes.

>

Re: [PHP-DEV] Experimental features

[juan carlos morales]

My small contribution to this 

First of all, nice you picked "json_validate()" for your example,
thanks for this, somehow, support! :)

Second...

Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive
... ini setting that affects the behavior of PHP somehow, then ...
maybe applying the PECL strategy might not be the most confortable way
to approach it, OR ... what about a new sensitive funtion in a "core
extension" like JSON?

An Experimental feature is something that WE want it to be in such a
way because we want to see how the feature behaves, and what can of
feedback can we get out of it.

In case this proposal is accepted, it will change the RFC process for
sure in order to indicate if its experimental or not.

I think Experimental features , no matther what they are, should be
backup with a consistent monitoring strategy around them something
to keep in mind; This proposal is more about workflows in the PHP
project than something else.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[David Rodrigues]

Hi Flávio and Hans!

> Could this be done through extensions instead of having to develop a new
process/support code?

I believe it is possible, however, the main part of the idea would be that
"common users" could try out the features without having to know how to
install extensions, while there is an explicit notion that the feature used
is experimental (via experimental_() prefix for functions or method, for
instance) and that the goal is to test it to become part of PHP itself at
some point, not more as an extension but as a native part. So if these
experimental extensions are available natively and enabled by default, it
would be interesting, because it would be easier to separate the main code
from the code in development/refinement (and that can be rejected at some
point in a more practical way, and maybe be kept as just an extension apart
from PHP).




Atenciosamente,
David Rodrigues


Em ter., 4 de out. de 2022 às 19:37, Flávio Heleno 
escreveu:

> On Tue, Oct 4, 2022, 17:43 David Rodrigues  wrote:
>
>> I wanted to suggest the possibility of introducing experimental features
>> to
>> PHP.
>>
>> This is an old thread I guess, but I think it's good to reevaluate the
>> situation from time to time, as other languages already do this to some
>> extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
>> libraries (React) bring features natively in an experimental way.
>>
>> I wanted to propose that we bring this idea into PHP, so we wouldn't have
>> to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out
>> these
>> new features, and so when these versions arrive, they'll already be quite
>> polished, avoiding patches sometime later due to wider usage of users.
>>
>> My idea is to have two levels of experimental features:
>>
>> (1) Via declare(), when the feature affects how PHP can act when reading
>> the file itself. Eg. declare(experimental_operator_override =
>> true), Something that happens with Kotlin, for example, when we use some
>> experimental annotations like contracts. These declarations work "per
>> file", so whenever it is necessary to use it, it must be declared.
>>
>> (2) Via experimental identifier name. Eg. experimental_json_validate() or
>> Experimental::json_validate(), like in Kotlin and also in React.
>>
>> Experimental features can only be brought into a minor version (eg. PHP
>> 8.1.12) when it is minimally refined and practically ready to use. It
>> would
>> be "kind of" an expected final version, no new patches are expected (we
>> hope), unless something really went unnoticed.
>>
>> Despite this, experimental features may not exist until the next
>> major/minor release if its practical inefficiency is found or if the
>> concept is shown to be invalid. So it should always be a "use with care".
>>
>> However, if an experimental feature is successful, it becomes final at the
>> next major/minor or major/minor+1. The experimental version becomes an
>> alias during some future versions until it is removed entirely. This is
>> the
>> time for users to adapt their code and for IDEs to help us find them.
>>
>> With this, we can understand whether users are making use of a certain
>> feature or not, make improvements on it, etc.
>>
>> I notice that many good features are rejected because they are believed to
>> be bad for PHP or can be confusing, but without any practical testing.
>> Experimental features can make this analysis more grounded in practical
>> data than just possibilities.
>>
>> However, this also doesn't mean that any idea can become an experimental
>> feature, but ideas that have a good foundation and a good discussion
>> before
>> it. The difference is that the feature can be tested in practice before
>> being totally rejected, and approved features can be delivered ahead of
>> time to refine before the next version is released, allowing users to try
>> them out more easily.
>>
>>
>> Atenciosamente,
>> David Rodrigues
>>
>
> Hi David,
>
> Could this be done through extensions instead of having to develop a new
> process/support code?
>
> When json support was first introduced into php, it was done as an
> extension and then, after a while, incorporated into the core.
>
>
>

Re: [PHP-DEV] Experimental features

[Hans Henrik Bergan]

sounds like that's been done with PECL previously yeah?
PECL json until native json_encode in PHP5.2.0,
PECL PDO until native PDO in PHP 5.1.0,
PECL ZendOpcache until native opcache in PHP 5.5.5
etc?

On Wed, 5 Oct 2022 at 00:38, Flávio Heleno  wrote:
>
> On Tue, Oct 4, 2022, 17:43 David Rodrigues  wrote:
>
> > I wanted to suggest the possibility of introducing experimental features to
> > PHP.
> >
> > This is an old thread I guess, but I think it's good to reevaluate the
> > situation from time to time, as other languages already do this to some
> > extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
> > libraries (React) bring features natively in an experimental way.
> >
> > I wanted to propose that we bring this idea into PHP, so we wouldn't have
> > to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out these
> > new features, and so when these versions arrive, they'll already be quite
> > polished, avoiding patches sometime later due to wider usage of users.
> >
> > My idea is to have two levels of experimental features:
> >
> > (1) Via declare(), when the feature affects how PHP can act when reading
> > the file itself. Eg. declare(experimental_operator_override =
> > true), Something that happens with Kotlin, for example, when we use some
> > experimental annotations like contracts. These declarations work "per
> > file", so whenever it is necessary to use it, it must be declared.
> >
> > (2) Via experimental identifier name. Eg. experimental_json_validate() or
> > Experimental::json_validate(), like in Kotlin and also in React.
> >
> > Experimental features can only be brought into a minor version (eg. PHP
> > 8.1.12) when it is minimally refined and practically ready to use. It would
> > be "kind of" an expected final version, no new patches are expected (we
> > hope), unless something really went unnoticed.
> >
> > Despite this, experimental features may not exist until the next
> > major/minor release if its practical inefficiency is found or if the
> > concept is shown to be invalid. So it should always be a "use with care".
> >
> > However, if an experimental feature is successful, it becomes final at the
> > next major/minor or major/minor+1. The experimental version becomes an
> > alias during some future versions until it is removed entirely. This is the
> > time for users to adapt their code and for IDEs to help us find them.
> >
> > With this, we can understand whether users are making use of a certain
> > feature or not, make improvements on it, etc.
> >
> > I notice that many good features are rejected because they are believed to
> > be bad for PHP or can be confusing, but without any practical testing.
> > Experimental features can make this analysis more grounded in practical
> > data than just possibilities.
> >
> > However, this also doesn't mean that any idea can become an experimental
> > feature, but ideas that have a good foundation and a good discussion before
> > it. The difference is that the feature can be tested in practice before
> > being totally rejected, and approved features can be delivered ahead of
> > time to refine before the next version is released, allowing users to try
> > them out more easily.
> >
> >
> > Atenciosamente,
> > David Rodrigues
> >
>
> Hi David,
>
> Could this be done through extensions instead of having to develop a new
> process/support code?
>
> When json support was first introduced into php, it was done as an
> extension and then, after a while, incorporated into the core.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Flávio Heleno]

On Tue, Oct 4, 2022, 17:43 David Rodrigues  wrote:

> I wanted to suggest the possibility of introducing experimental features to
> PHP.
>
> This is an old thread I guess, but I think it's good to reevaluate the
> situation from time to time, as other languages already do this to some
> extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
> libraries (React) bring features natively in an experimental way.
>
> I wanted to propose that we bring this idea into PHP, so we wouldn't have
> to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out these
> new features, and so when these versions arrive, they'll already be quite
> polished, avoiding patches sometime later due to wider usage of users.
>
> My idea is to have two levels of experimental features:
>
> (1) Via declare(), when the feature affects how PHP can act when reading
> the file itself. Eg. declare(experimental_operator_override =
> true), Something that happens with Kotlin, for example, when we use some
> experimental annotations like contracts. These declarations work "per
> file", so whenever it is necessary to use it, it must be declared.
>
> (2) Via experimental identifier name. Eg. experimental_json_validate() or
> Experimental::json_validate(), like in Kotlin and also in React.
>
> Experimental features can only be brought into a minor version (eg. PHP
> 8.1.12) when it is minimally refined and practically ready to use. It would
> be "kind of" an expected final version, no new patches are expected (we
> hope), unless something really went unnoticed.
>
> Despite this, experimental features may not exist until the next
> major/minor release if its practical inefficiency is found or if the
> concept is shown to be invalid. So it should always be a "use with care".
>
> However, if an experimental feature is successful, it becomes final at the
> next major/minor or major/minor+1. The experimental version becomes an
> alias during some future versions until it is removed entirely. This is the
> time for users to adapt their code and for IDEs to help us find them.
>
> With this, we can understand whether users are making use of a certain
> feature or not, make improvements on it, etc.
>
> I notice that many good features are rejected because they are believed to
> be bad for PHP or can be confusing, but without any practical testing.
> Experimental features can make this analysis more grounded in practical
> data than just possibilities.
>
> However, this also doesn't mean that any idea can become an experimental
> feature, but ideas that have a good foundation and a good discussion before
> it. The difference is that the feature can be tested in practice before
> being totally rejected, and approved features can be delivered ahead of
> time to refine before the next version is released, allowing users to try
> them out more easily.
>
>
> Atenciosamente,
> David Rodrigues
>

Hi David,

Could this be done through extensions instead of having to develop a new
process/support code?

When json support was first introduced into php, it was done as an
extension and then, after a while, incorporated into the core.

[PHP-DEV] Experimental features

[David Rodrigues]

I wanted to suggest the possibility of introducing experimental features to
PHP.

This is an old thread I guess, but I think it's good to reevaluate the
situation from time to time, as other languages already do this to some
extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
libraries (React) bring features natively in an experimental way.

I wanted to propose that we bring this idea into PHP, so we wouldn't have
to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out these
new features, and so when these versions arrive, they'll already be quite
polished, avoiding patches sometime later due to wider usage of users.

My idea is to have two levels of experimental features:

(1) Via declare(), when the feature affects how PHP can act when reading
the file itself. Eg. declare(experimental_operator_override =
true), Something that happens with Kotlin, for example, when we use some
experimental annotations like contracts. These declarations work "per
file", so whenever it is necessary to use it, it must be declared.

(2) Via experimental identifier name. Eg. experimental_json_validate() or
Experimental::json_validate(), like in Kotlin and also in React.

Experimental features can only be brought into a minor version (eg. PHP
8.1.12) when it is minimally refined and practically ready to use. It would
be "kind of" an expected final version, no new patches are expected (we
hope), unless something really went unnoticed.

Despite this, experimental features may not exist until the next
major/minor release if its practical inefficiency is found or if the
concept is shown to be invalid. So it should always be a "use with care".

However, if an experimental feature is successful, it becomes final at the
next major/minor or major/minor+1. The experimental version becomes an
alias during some future versions until it is removed entirely. This is the
time for users to adapt their code and for IDEs to help us find them.

With this, we can understand whether users are making use of a certain
feature or not, make improvements on it, etc.

I notice that many good features are rejected because they are believed to
be bad for PHP or can be confusing, but without any practical testing.
Experimental features can make this analysis more grounded in practical
data than just possibilities.

However, this also doesn't mean that any idea can become an experimental
feature, but ideas that have a good foundation and a good discussion before
it. The difference is that the feature can be tested in practice before
being totally rejected, and approved features can be delivered ahead of
time to refine before the next version is released, allowing users to try
them out more easily.


Atenciosamente,
David Rodrigues