On Tuesday, 11 March 2025 at 21:17, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote: > On 11/03/2025 11:54, Gina P. Banyard wrote: > > > It also means that we need to do multiple passes, on the same code path, > > resulting in somewhat of a code churn and possibly not using a common > > abstraction. > > Considering that we didn't even have the time to properly remove some > > deprecations from PHP 7 with the PHP 8.0.0 release, nor convert all > > relevant E_WARNINGs to Value/Type errors, I expect that we would be missing > > some of them again when PHP 9 comes around. > > I wonder if in some cases, we could automate this within the source code > - e.g. with a macro like WARNING_OR_ERROR(message, > first_version_for_error) which checks a compile-time constant for the > current version. I realise that still requires code cleanup later, but > it means we can't miss our chance when the appropriate version does come > around.
I don't think this is an improvement for the maintenance side. > > and this is ignoring the fact that PHP does not follow semver > > This is true, but only in the sense that something under the MIT license > isn't under the BSD license. Officially, PHP's release policy is > extremely similar to SemVer. > > [...] > > Now, what exactly constitutes "backward compatibility" and "userland API > compatibility" can be debated, but there is currently no agreed policy > allowing "small compatibility breaks". > > The fact that everyone acts as though there is such a policy, probably > means a rewrite of that document is overdue. A policy that nobody > follows is no use to either contributors or users. Yes, rewriting this policy would be a good idea. There have been BC breaks in every minor release going all the way back to PHP 4. > Maybe we could work on some criteria that could be applied (and > publicised to users) about what is and isn't allowed in minor versions. > > [...] > > We'd probably still want some kind of deprecation policy - some changes > should be deprecated for X releases before removal/change. Which brings > us back to some kind of criteria for which changes need that, so doesn't > really solve the problem. Indeed, none of this really solves the problem. I think it is *fair* that the Core language has more stringent requirements on BC than anything else. The standard library being second in line for this sort of considerations. But every other bundled extension should be allowed to have way more leeway in what said extension maintainer wants to do. Making a distinction between Type and Value errors is meaningless to me, if PHP had a stronger type system, e.g. dependent types, then, a lot of things we currently consider ValueErrors would be TypeErrors. If we were also designing some of these functions from scratch today, a lot of parameters wouldn't integers, but enums. The only exception to this are bitmask parameters, as we don't have Enum Sets (or Intersection Types as values) which would replace those. And again, ValueErrors are only ever added when it *easy* to check if the condition is satisfied, and it very clearly points to a programming error. I still find it baffling that telling someone that the code they wrote, even if it is decades old, is incorrect is somehow bad. Because the alternative is letting users have bugs in their software that they can ignore. Best regards, Gina P. Banyard
