Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111321
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJduksnOvu_2q_cy1MF1cR1OvXkEeUchk_5aX2fshsd3NDYw@mail.gmail.com>
In-Reply-To: <CAEPJduksnOvu_2q_cy1MF1cR1OvXkEeUchk_5aX2fshsd3NDYw@mail.gmail.com>
Date: Tue, 4 Aug 2020 10:01:40 -0500
Message-ID: <CAESVnVpDBHGbpREJfNcmRgpzrfxUrmLsV-Pa8a8DWo92yWO1Vw@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000fe5d405ac0e8945"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: pollita@php.net (Sara Golemon)

--0000000000000fe5d405ac0e8945
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei <kontakt@beberlei.de> wrote:

> It provides a small BC break where code written as @[$foo, $bar] = baz();
> or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can
> be easily
> fixed by writing it with a space between @ and [.
>
> If those are the potential breaks we're choosing between, I would favor
#[...] as it provides strong forward-compatibility to drive adoption and
use at the cost of a parse error that's easily fixed (even programmatically
with a very simple script).   @[...] provides no forward compat with a
roughly equal chance of easily fixed syntax break.

Given that, the choice seems obvious to me.
Change my mind?

-Sara

--0000000000000fe5d405ac0e8945--