> You said in one of your answers something like "one project holding back > the PHP language". While in essence true, Wordpress is not just any > project -- it's still the biggest multiplicator for PHP usage. The > amount of deprecation logs printed on a daily basis, the amount of > support generated, and the general impact will be huge.
I'll be honest, the size of the project isn't the part I find relevant. The objection only works if you assume a chain that doesn't actually happen: that merging this deprecation means every WP instance upgrades, that PHP 9.0 appears out of nowhere, and that apps break the next morning. None of those steps are automatic or imminent. A deprecation in 8.6 emits a notice; it is not an error and nothing stops working, regardles of how many `list()` instances are in the codebase. Actual removal is 9.0, which is years away. And instances don't upgrade themselves. A site must be actively moved onto a version that removed the construct before anything can break, and a site nobody maintains isn't being moved anywhere. So the "huge impact" is, at worst, deprecation notices in logs during a multi-year window that exists precisely to absorb them. That's true whether WordPress has one instance or a hundred million; the count doesn't change what a notice is. No project steers the language for me, WordPress included. but I don't even need that principle here. The scenario people are picturing just isn't the one the deprecation cycle produces. > `array_destruct()` that would address the readability argument (which is > hard to discuss away because it is hyper subjective). This can't work, and not for stylistic reasons. Destructuring happens in a *write* context: the construct sits on the left of `=` and receives bindings. A function can't do that. `array_destruct($a, $b) = $arr` isn't expressible, functions return values, they don't accept assignment targets. So a function couldn't replace `list()`; you'd need a new *construct* to stand in for it, which means adding grammar rather than removing it. That's the opposite of what the RFC is trying to do. This is also the crux of the readability point, I think: `list()` looks like a function precisely because of the parentheses, but it isn't one, and that mismatch is part of what makes the name misleading in the first place.
