Re: Experimental features

> On 6 Oct 2022, at 16:06, Rowan Tommins <rowan.collins@gmail.com> 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<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