# Experimental features

- Thread: https://externals.io/message/118740
- Original archive: https://news-web.php.net/php.internals/118740
- Started by David Rodrigues on 2022-10-04T20:42:28+00:00
- Messages: 38
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/118740.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #118740 — David Rodrigues — 2022-10-04T20:42:28+00:00

URL: https://externals.io/message/118740#118740

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

---

## #118741 — flaviohbatista@gmail.com — 2022-10-04T22:37:47+00:00

URL: https://externals.io/message/118740#118741 · In reply to: #118740

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

---

## #118742 — Hans Henrik Bergan — 2022-10-04T22:47:09+00:00

URL: https://externals.io/message/118740#118742 · In reply to: #118741

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?


>
> 
>
> > […]
>
> 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.

---

## #118743 — David Rodrigues — 2022-10-04T22:52:04+00:00

URL: https://externals.io/message/118740#118743 · In reply to: #118741

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 <flaviohbatista@gmail.com>
escreveu:

> 
>
> > […]
>
> 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.

---

## #118749 — juan carlos morales — 2022-10-05T10:54:11+00:00

URL: https://externals.io/message/118740#118749 · In reply to: #118743

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.

---

## #118750 — Deleu — 2022-10-05T11:16:14+00:00

URL: https://externals.io/message/118740#118750 · In reply to: #118749

On Wed, Oct 5, 2022, 7:54 AM juan carlos morales <dev.juan.morales@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.

---

## #118751 — flaviohbatista@gmail.com — 2022-10-05T12:28:26+00:00

URL: https://externals.io/message/118740#118751 · In reply to: #118750

> On Wed, Oct 5, 2022, 7:54 AM juan carlos morales <
> dev.juan.morales@gmail.com>
> wrote:
>
> > […]
>
> 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

---

## #118752 — Alex Wells — 2022-10-05T13:38:17+00:00

URL: https://externals.io/message/118740#118752 · In reply to: #118741

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 <flaviohbatista@gmail.com>
wrote:

> 
>
> > […]
> to
> > […]
> these
> > […]
> would
> > […]
> the
> > […]
> the
> > […]
> to
> > […]
> before
> > […]
>
> 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.

---

## #118754 — Christian Schneider — 2022-10-05T16:02:14+00:00

URL: https://externals.io/message/118740#118754 · In reply to: #118752

Am 05.10.2022 um 15:38 schrieb Alex Wells <autaut03@gmail.com>:
> 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

---

## #118755 — David Rodrigues — 2022-10-05T17:06:58+00:00

URL: https://externals.io/message/118740#118755 · In reply to: #118754

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 <
cschneid@cschneid.com> escreveu:

> Am 05.10.2022 um 15:38 schrieb Alex Wells <autaut03@gmail.com>:
> > […]
>
> 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
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #118756 — Rowan Tommins — 2022-10-05T17:41:12+00:00

URL: https://externals.io/message/118740#118756 · In reply to: #118755

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

---

## #118764 — Alex Wells — 2022-10-06T11:16:57+00:00

URL: https://externals.io/message/118740#118764 · In reply to: #118756

> 
> 
> 
> 
> > […]
> 
> 
> 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.

---

## #118765 — Christoph M. Becker — 2022-10-06T12:26:22+00:00

URL: https://externals.io/message/118740#118765 · In reply to: #118740

> 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] <https://wiki.php.net/rfc/releaseprocess#releases_cycle>

--
Christoph M. Becker

---

## #118766 — Alex Wells — 2022-10-06T13:00:51+00:00

URL: https://externals.io/message/118740#118766 · In reply to: #118765

> 
> 
> 
> 
> > […]
> 
> 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] <https://wiki.php.net/rfc/releaseprocess#releases_cycle>
> 
> --
> Christoph M. Becker
> 
> --
> 
> 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.

---

## #118767 — Rowan Tommins — 2022-10-06T13:06:32+00:00

URL: https://externals.io/message/118740#118767 · In reply to: #118764

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

---

## #118769 — Alex Wells — 2022-10-06T16:41:21+00:00

URL: https://externals.io/message/118740#118769 · In reply to: #118767

> 
> 
> 
> > […]
> 
> 
> 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?
> 
> 
> > […]
> 
> 
> 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]
> 
> -- 
> 
> 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<String>) {
    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<String>) {
    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 consumer of that function would be required to opt-in:

```php
#[OptIn(ExperimentalJsonValidate::class)]
function main() {
    `json_validate()`; // all good
}
```

If an opt-in is missing, PHP will trigger an warning (during runtime):

```php
function main() {
    `json_validate()`; // trigger_error('Must be opted-in', E_WARNING)
}
```

Few months after the release (let's say 8.2), PHP collects feedback and analyses codebases (which is easy thanks to the attribute) and decides it wants to change the name to `json_revalidate`. This is of course over exaggerated, but it's to prove the point. Just as any other change in PHP, this would require an RFC. If it's accepted, the change is done.

Under regular circumstances (no experimental features), such a change would have to at least have a deprecation notice for one minor/major release prior to it (so the minimum version this could be done in is 8.4). Moreover, such changes would usually be avoided at all costs, because this is a big breaking change. 

Experimental features on the other hand are explicit opt-in - users know it can be changed at any time, without a warning, a deprecation or anything for that matter, in any release. That allows the change to be done without really worrying of BC and also much earlier (8.3 or even 8.2.1 if you decide so). Also, the `#OptIn` attribute allows consumers to easily find all places where an experimental feature was used in case a breaking change was done.

The same concept can also be applied to new syntax - let's say generics, except with a more strict error (E_FATAL, for example). This has been briefly discussed here: https://github.com/PHPGenerics/php-generics-rfc/issues/49

---

## #118771 — Rowan Tommins — 2022-10-06T20:12:06+00:00

URL: https://externals.io/message/118740#118771 · In reply to: #118769

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

---

## #118772 — Alex Wells — 2022-10-06T21:36:28+00:00

URL: https://externals.io/message/118740#118772 · In reply to: #118771

> 
> 
> 
> > […]
> 
> 
> 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]
> 
> -- 
> 
> 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).

---

## #118773 — Jordan LeDoux — 2022-10-06T21:38:22+00:00

URL: https://externals.io/message/118740#118773 · In reply to: #118771

On Thu, Oct 6, 2022 at 1:12 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> 
> > […]
> 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

---

## #118774 — David Rodrigues — 2022-10-06T21:40:42+00:00

URL: https://externals.io/message/118740#118774 · In reply to: #118771

> 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 <rowan.collins@gmail.com>
escreveu:

> 
> > […]
> 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]
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #118775 — Christian Schneider — 2022-10-07T06:57:26+00:00

URL: https://externals.io/message/118740#118775 · In reply to: #118774

Am 06.10.2022 um 23:40 schrieb David Rodrigues <david.proweb@gmail.com>:
> 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

---

## #118776 — G. P. B. — 2022-10-07T10:58:07+00:00

URL: https://externals.io/message/118740#118776 · In reply to: #118775

On Fri, 7 Oct 2022 at 07:57, Christian Schneider <cschneid@cschneid.com>
wrote:

> But now to my main point: You are talking about the most simple and
> isolated case, a new function.
>

I agree, and for most intent and purposes a function can be polyfilled in
userland. So this is the least interesting case.

However, I don't think this approach is that useful. To give an example,
for DNF types the implementation is based on a change in how iterable works
in PHP.
It went from a pseudo-type to a compile time alias, as this massively
simplified variance and LSP checks.
I would not want such a change to land in a patch release especially as it
turned out there was an unintended BC break with the compile time
redundancy which only got fixed in PHP8.2RC2.


> Your model may work fine with that but as soon as we are talking something
> like a syntax change we have some additional problems:
> - Enabling it with a prefix obviously does not work, something like
> declare() is definitely needed
> - Maintaining such changes to the engine / parser could turn out messy,
> e.g. lots of "if (experimental_x)"-like code in the core
> - The test suite would possibly have to deal with an exponential explosion
> of experimental feature combinations to make sure they don't interfere with
> each other.
>
> All in all I'm not sold yet that the benefit outweighs the cost of this
> approach.
>

Ditto.

When Nikita proposes editions back in 2020 (
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md)
the point about them was mainly about backwards-incompatible changes, not
new features.
Because in general new features don't have the same issues, especially
since the RFC process (although not without its issues) does force thinking
about the design of it instead of just shoving something in php-src
randomly as in the before days.

Best regards,

George P. Banyard

---

## #118780 — Larry Garfield — 2022-10-07T15:44:36+00:00

URL: https://externals.io/message/118740#118780 · In reply to: #118776

> On Fri, 7 Oct 2022 at 07:57, Christian Schneider <cschneid@cschneid.com>
> wrote:
>
> > […]
>
> 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.
>
>
> > […]
>
> Ditto.
>
> When Nikita proposes editions back in 2020 (
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md)
> the point about them was mainly about backwards-incompatible changes, 
> not
> new features.
> Because in general new features don't have the same issues, especially
> since the RFC process (although not without its issues) does force 
> thinking
> about the design of it instead of just shoving something in php-src
> randomly as in the before days.
>
> Best regards,
>
> George P. Banyard

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

---

## #118782 — Alex Wells — 2022-10-07T15:58:54+00:00

URL: https://externals.io/message/118740#118782 · In reply to: #118780

> 
> 
> 
> > […]
> 
> 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
> 
> -- 
> 
> 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.

---

## #118787 — Rowan Tommins — 2022-10-08T18:31:41+00:00

URL: https://externals.io/message/118740#118787 · In reply to: #118780

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

---

Next page: https://externals.io/message/118740.md?page=2