Re: [RFC] Deprecations for PHP 8.6
| From: | Seifeddine Gmati | Date: | Wed, 01 Jul 2026 19:25:05 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 8.6 | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131673@lists.php.net to get a copy of this message | ||
On Wed, 1 Jul 2026 at 18:31, Tim Düsterhus <tim@bastelstu.be> wrote:
>
> Hi
>
> Am 2026-06-29 20:37, schrieb Seifeddine Gmati:
> > 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.
>
Hi Tim,
> FWIW: I still have a rough draft to make array() (or rather:
> all
> non-object types) proper functions that effectively would “stand in” as
> cast operators. For array() specifically this would allow a
> named-argument style of defining arrays with “unquoted keys”:
> array(foo: 1, bar: 2).
This would require deprecating array() first anyway, no? Otherwise,
dealing with it during parsing would be hacky (looking ahead at
array(foo for : or => or , or )
to decide if it's an array
or a function call, possible, but hacky think ).