Re: [RFC] Deprecations for PHP 8.6

> So my ivory tower remark is on point. I find this hard to answer, because one message ago the objection was that I'd never been in a position to make a pragmatic decision, and now it's that I have too much expertise to relate to ordinary users. Both can't be the problem. I only mentioned what I do because you'd told me, flatly, that I hadn't done it. > The problem is the disdain and indifference you've shown to people who's skills > aren't up to par with yours. I don't hold that, and nothing I argued requires it. Wanting fewer people caught out by a change is a fair instinct to have, I don't think you're wrong to care about it. My point was narrower and not about anyone's skill: the existence of unmaintained software shouldn't permanently freeze the language. That's a claim about deprecation policy, not about the people running those sites. And it matters that a deprecation breaks nothing on upgrade day. It emits a notice; removal is a full major version away, years out. A site nobody maintains also isn't chasing new PHP majors, the two go together. For an abandoned plugin to suddenly stop working, someone must actively move it to a major version that removed the feature. Does WordPress even allow upgrading to a PHP version its plugins don't support? I don't know. If a managed host does that somehow, without checking compatibility, the failure isn't in the language. > for what? The code reads prettier to you. That isn't the motivation. If that were, I'd let a formatter handle it. The reasons are a simpler grammar, freeing the list keyword for a possible future list type, and removing a redundant construct newcomers otherwise have to learn for no reason. You can think those aren't worth the churn; that's a legitimate disagreement. "its prettier" isn't what's actually being proposed. And this is what I keep coming back to: why this deprecation in particular? The same RFC deprecates several other things, and at least one of them is genuinely harder to migrate than list(), which makes the focus on list() odd. Take the deprecation of _() in favour of gettext() (which is reasonable, given _ is being reserved for another purpose). That looks like a trivial find-and-replace, but it isn't safe. PHP resolves an unqualified function call by checking the current namespace first and only then falling back to global. So inside namespace App;, a bare _(...) binds to App\_ if that function exists, and only otherwise to the global _. Blindly rewriting _ to gettext can therefore change which function actually runs, if there's an App\gettext, the rewritten call now resolves to it instead of the global one. A purely syntactic tool like ast-grep cannot catch that, because it's a whole-program resolution fact, not a textual one. You'd need a type-aware linter that indexes the entire codebase to do it safely. list() -> [] has none of that. The compiler emits identical opcodes (see the 3v4l link above). So it's the one case where a one-line ast-grep rewrite is provably correct. If anything, list() is the *safest* migration in the entire RFC, and the harder ones (the ones that can actually cause issues) aren't the ones drawing the objection. I also doubt the abandoned plugins you're picturing are pristine on every other deprecation in the RFC and happen to trip only on list(. If "some plugins are unmaintained" blocks this, it blocks all of it, and PHP should never deprecate anything, and we should freeze the language as it is now. > Being a better coder doesn't make you a better person. Where exactly did I give you the impression that I think I'm a better person? We are having a technical discussion; you are turning it personal. Cheers, Seifeddine