Re: Experimental features

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