On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP]
<[email protected]> wrote:
>
> On 29/06/2026 17:37, Seifeddine Gmati wrote:
> > Hello Internals,
> >
> > I have updated the RFC to include a deprecation proposal for the
> > `list()` construct.
> >
> > ref:
> > https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct
>
>
> I don't think it makes sense to deprecate list() if we're not
> deprecating array() - they're exact counterparts, and both replaced by
> the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4,
> but as a replacement for list() was only added in PHP 7.1.
I'm actually in favor of deprecating `array()` too, and I raised this
on the #php-internals Discord channel. The motivation there is weaker
though: unlike `list`, deprecating `array()` does not free up a
keyword, since `array` remains a type. The grammar simplification and
having fewer things for newcomers to learn still apply, and IMO are
good reasons on their own. If there's appetite for it, I'm happy to
add it to the RFC.
> I agree that it's not immediately clear that array() constructs and
> list() extracts, but I think your example is unfair, because both
> array($a, $b) and list("a" => $a, "b" => $b) are also valid.
The example isn't claiming the two forms can't be written the other
way around. The point is purely about how they read: set next to
`array("a" => $a, "b" => $b)`, the construct `list($a, $b)` looks like
it builds some kind of list value, a sibling of `array()`, when in
fact it constructs nothing and instead pulls values out of an existing
array.
And `list("a" => $a, "b" => $b)` actually reinforces the case. In PHP
you can't tell a construct from a function call just by looking at it,
so someone reading that for the first time has no way to understand
why a "funtcion" called `list` is being called in a write context with
key/value pairs. The name actively misleads.
> A possible justification would be that one is more common than the
> other, but right now there's no discussion or analysis of that. (Which
> as I've said elsewhere in this thread will be an automatic "No" vote
> from me if it's still the case at voting time.)
I don't think relative frequency is the core justification here, so
I'd rather not anchor the RFC on usage numbers. The case rests on the
keyword being freed for a potential future `list` type, grammar
simplification, and the readability point above, regardless of which
form is more common.
Cheers,
Seifeddine.
