Re: [RFC] Deprecations for PHP 8.6

On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> 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: ˜( > > }y|âõ›òïÕÆ$fIhttps://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.