> On 6 Oct 2022, at 23:12, Rowan Tommins <rowan.coll...@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).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
