On Mon, 29 Jun 2026 at 18:51, Ayesh Karunaratne <[email protected]> wrote: > > > 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 > > > > Hi Seifeddine, > I understand the reasoning behind freeing up the `list` keyword and > having a canonical way to destructure an array. However, I would argue > that the scale of this BC break far outweighs the benefits. > > A quick GitHub code search shows 7 million[^1] hits for "list(" in PHP > files.
That 7 million figure is misleading, as it also matches methods and functions with a `list` suffix. Excluding forks, archived, generated, and vendored code, and searching only for ` list($` brings it down to roughly 1 million: https://github.com/search?q=%22+list%28%24%22+lang%3Aphp+NOT+is%3Afork+NOT+is%3Aarchived+NOT+is%3Agenerated+NOT+is%3Avendored&type=code > [...] If we deprecate and eventually drop `list()` in PHP 9, we can > safely assume that a large portion of existing code will fail to > compile in PHP 9. That's the purpose of the deprecation period: like any feature or syntax that gets removed, it gives people time to migrate away from the old construct. In this case the migration is purely mechanical, and the RFC already provides a one-liner for it: `ast-grep run --pattern 'list($$$ARGS)' --rewrite '[$$$ARGS]' --lang php -U` > Furthermore, the documentation for `list()` offers no hint that `[]` > is preferred over `list()`, and I would also argue that there is no > reason to prefer one over the other. Code-style guides can dictate a > project's or library's conventions, but we should take a more > conservative approach if we really have a strong technical reason to > prefer one syntax over another. `list()` does not currently recommend `[]` because it has not yet been deprecated, and it exists only as an alternative syntax for `[]` in write positions ( post 7.1 ). Once deprecated, the documentation and coding styles will have to adopt the change. A library's stylistic preference for a redundant syntax should not dictate language design; it should follow the change. > Based on the RFC text, aside from freeing up the `list` keyword for > potential future use, I do not see a sufficiently strong technical > reason to deprecate `list()`. Freeing up the `list` keyword for a potential future `list` type is indeed the main motivation, but not the only one: it also simplifies the language grammar and leaves newcomers with fewer things to learn. Cheers, Seifeddine.
