Re: [RFC] Deprecations for PHP 8.6
| From: | Tim Düsterhus | Date: | Thu, 02 Jul 2026 07:53:27 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 8.6 | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131701@lists.php.net to get a copy of this message | ||
Hi
Am 2026-07-01 21:25, schrieb Seifeddine Gmati:
It's not particularly pretty, but possible. TheFWIW: I still have a rough draft to makeThis would require deprecatingarray()(or rather: all non-object types) proper functions that effectively would “stand in” as cast operators. Forarray()specifically this would allow a named-argument style of defining arrays with “unquoted keys”:array(foo: 1, bar: 2).array()first anyway, no? Otherwise, dealing with it during parsing would be hacky (looking ahead atarray(foofor:or=>or,or)to decide if it's an array or a function call, possible, but hacky think ).
array() syntax will not actually be a function call, it will just look like one. Basically the : syntax can just parse into the same AST as the => syntax, the grammar just needs to make sure that they may not be mixed. The array() function will be made available in addition to support \array (i.e. with a fully-qualified name) and array(...) (i.e. a first class callable).
My rough draft is in https://github.com/php/php-src/pull/18613, I think there are some issues still with properly compiling the array, because the AST node for => takes the two sides in different order compared to named arguments and I wanted to document the AST structure first (and then got distracted by more important things).
Best regards
Tim Düsterhus