> 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.coll...@gmail.com> 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 > >
