> 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.
