Re: [RFC] Deprecations for PHP 8.6

> Please look again on the same page. The _recommended_ version may be PHP 8.3, the minimum > version ("Running on legacy versions?") is PHP 7.4 and only since recently. 8.3 is listed as the version up top, and 7.4 appears under "Running on legacy versions?", which the page itself flags as EOL and recommends upgrading away from. I'm not sure an End-Of-Life floor is the number we should be designing around, but it doesn't matter either way: [] destructuring has worked since PHP 7.1, so it's supported on every version WP runs on, 7.4 and 8.3 alike. The short syntax isn't version-gated for them under any reading of that page. > That's just plain untrue. The one is used for creating an array, the other for > destructuring an array. You're correct, and I mistyped there. But that's a rewrite detail, not the point I was making. My point was about the *name*. The accessibility argument was that the keyword lets you tell "a list or an array" apart at a glance, and that's what i disagree on, because PHP has no list. list() doesn't construct anything; it destructures an array. The keyword names a type that doesn't exist, and it accepts keys (list("foo" => $bar) = $arr), which a genuine "list" wouldn't. So "the keyword tells you what it is" is exactly backwards here: the keyword tells you something false. > Agreed, but that doesn't take anything away from the fact that WP uses it as an argument > against switching to the short syntax. I haven't seen anyone from the WP team make that argument in this thread, so I'd be cautious about treating it as WP's settled position rather than a reason attributed to them. And more importantly: even if it is their position, a single project's style preference shouldn't steer language design. Coding styles adapt to what the language offers *at the version they target*; that's the normal direction of the relationship. A project choosing to keep array()/list() in their own codebase is entirely their call, and deprecating the long forms doesn't force them to restyle historical code on any particular timeline. But "we'd rather keep writing it the old way" isn't a reason for the language to carry a redundant construct indefinitely.