Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111323 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 89019 invoked from network); 4 Aug 2020 16:30:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Aug 2020 16:30:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id ADBBC18054A for ; Tue, 4 Aug 2020 08:28:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Tue, 4 Aug 2020 08:28:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 33FEE10C06B; Tue, 4 Aug 2020 16:28:24 +0100 (BST) Date: Tue, 4 Aug 2020 16:28:23 +0100 (BST) X-X-Sender: derick@singlemalt.home.derickrethans.nl To: Sara Golemon cc: Benjamin Eberlei , PHP Developers Mailing List In-Reply-To: Message-ID: References: User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1414684493-1596554904=:7489" Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: derick@php.net (Derick Rethans) --8323329-1414684493-1596554904=:7489 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 4 Aug 2020, Sara Golemon wrote: > On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei wro= te: >=20 > > It provides a small BC break where code written as @[$foo, $bar] =3D=20 > > baz(); or $foo =3D @["bar" =3D> $baz]; will not compile on PHP 8=20 > > anymore, but that can be easily fixed by writing it with a space=20 > > between @ and [. > > > If those are the potential breaks we're choosing between, I would=20 > favor #[...] as it provides strong forward-compatibility to drive=20 > adoption and use at the cost of a parse error that's easily fixed=20 > (even programmatically with a very simple script). @[...] provides no=20 > forward compat with a roughly equal chance of easily fixed syntax=20 > break. >=20 > Given that, the choice seems obvious to me. Change my mind? I pretty much agree, but @[ =E2=80=A6 ] is there as a compromise as it does= show=20 some fmailiarity with the already existing @ in doc blocks. cheers, Derick --=20 PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug --8323329-1414684493-1596554904=:7489--