Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111362
To: Benas IML <benas.molis.iml@gmail.com>, Rowan Tommins
	<rowan.collins@gmail.com>
CC: PHP Internals List <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Thread-Index:
 AQHWamWKUBRwNDrYsUOzfoBQKi8o6KkoJexGgAKAW4CAAAhPgIAADw+AgAAJNoCAABvtAIAAbz82
Date: Thu, 6 Aug 2020 17:05:09 +0000
Message-ID:
 <BYAPR05MB65357345667E6A35EDD89025DE480@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
 <alpine.DEB.2.23.453.2008060741110.7489@singlemalt.home.derickrethans.nl>
 <20200806091749.64675445@mcmic-probook.opensides.be>
 <CANeKSiStbGZG+EOVDRfRuVo4MA7th16R-oP7V2xmPj3xHNxs_A@mail.gmail.com>
 <CALKiJKporEo8DitTBqom=u0onqwQU+MiWF45R61cGHXzU783Fw@mail.gmail.com>,<CANeKSiRivtUWsH8ySYVtjmz3JX8mrs-OJLEin_2V+A7xt18X+A@mail.gmail.com>
In-Reply-To:
 <CANeKSiRivtUWsH8ySYVtjmz3JX8mrs-OJLEin_2V+A7xt18X+A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [7ZIgpNKgQ4330P7EyBViwOoZ9Z/wus3z]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 12803235-1a6d-498a-fc3c-08d83a2ae042
x-ms-traffictypediagnostic: DM6NAM11HT110:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 9yDonXvJSBAuyanRkxncr2yVU7ST4NaBkHHyGAIZeKEqDLRy7elppa6DylT7hsK2rG2lTeXhLaqqVe9q+qdDk350T9SjvIkjYQV2uvqbDBCtxrbgtioqS5zepYsZJ1XGpwnY39vVDMgmv/AU7SGmMeEbmKcIbdUxvd/L5KViHQDUY5gD6a36bUpq/Ri9mnriazHEg8i91jJi9OFjcx/4YNvjcJVYB2oLSTijF7oz/u7pC11TDiDL9uTKyeSmdr5S
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 RA00KF4TzlZJvKKm40VUEt02qmF65+nJ+Mj0bV59+xHRGZmE/Mx2PWLHspagfBMQ1f51e4K6fT2GA/XNqSA4Pw+4Cke1TMbO9HJEjN3BLQK2dMD72V9ZGCy1pbuquiKZrSOcooiSqGykyQwdXBfKvQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT030.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 12803235-1a6d-498a-fc3c-08d83a2ae042
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 17:05:09.7199
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT110
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: theodorejb@outlook.com (Theodore Brown)

On Thu, Aug 6, 2020 at 5:24 AM Benas IML <benas.molis.iml@gmail.com> wrote:=
=0A=
=0A=
> On Thu, 6 Aug 2020 at 11:45, Rowan Tommins <rowan.collins@gmail.com> wrot=
e:=0A=
> =0A=
> > On Thu, 6 Aug 2020 at 09:12, Benas IML <benas.molis.iml@gmail.com> wrot=
e:=0A=
> >=0A=
> > > But by sacrificing a few very old codebases (that still use `#` not `=
//`)=0A=
> >=0A=
> > Do you have some basis for # only being used by "very old" codebases? A=
s=0A=
> > far as I'm aware, it's not deprecated, and while the PEAR style guide=
=0A=
> > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.=0A=
> >=0A=
> > I agree that it is probably rarer than //... and /*...*/ but let's avoi=
d=0A=
> > unnecessary hyperbole.=0A=
=0A=
> A grep search was done by someone in the mailing list in the original=0A=
> `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going=0A=
> to be a huge BC or not.=0A=
> =0A=
> Just about all of the matches were either from old codebases or from=0A=
> old PHP 3-5 Metasploit exploits, which are about 5-15 years old.=0A=
=0A=
Hi Benas,=0A=
=0A=
You can look at the grep search here: https://grep.app/search?q=3D%23%5B&fi=
lter[lang][0]=3DPHP=0A=
=0A=
The first BC break in the results is from an automated pentest=0A=
framework repository which was last updated four days ago. So it=0A=
seems like this is still code that is being used.=0A=
=0A=
Even the current Psalm static analysis tests use # to comment out an=0A=
array: https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5e=
b829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453=0A=
=0A=
Not that these individual examples are a big problem, they simply=0A=
illustrate that hash comments are still used in current projects,=0A=
sometimes in ways that the #[] attribute syntax would break.=0A=
=0A=
When it comes to the @[] alternative, it's harder to grep for actual=0A=
usages, since this string is used in virtually every email validation=0A=
regex. In any case, code like @[foo(), bar()] would no longer work=0A=
without putting a space between the error suppression operator and=0A=
array (which frankly looks pretty confusing):=0A=
=0A=
    $x =3D=0A=
    @ [Foo()]; // an array assignment with suppressed warnings=0A=
    @[Jit()] // an attribute=0A=
    function bar() {}=0A=
=0A=
If there were some important language improvement that depended on=0A=
breaking these syntaxes, maybe it would be justified. But so far I=0A=
haven't seen such a justification.=0A=
=0A=
> We are playing probabilities here but at the moment, no one has said=0A=
> any substantial argument why `@@` is better and thus, `@[...]` seems=0A=
> like a better option in the long term.=0A=
=0A=
While none of our syntax options are perfect, I believe @@ has the best=0A=
long-term tradeoffs because:=0A=
=0A=
- It doesn't break useful syntax=0A=
- It is equally or more concise than grouped attributes without adding=0A=
complexity to the parser/compiler=0A=
- It offers a clean, simple way to support nested attributes in the=0A=
future if we so desire=0A=
- It is conceptually closest to the docblock syntax the PHP community=0A=
is familiar with=0A=
- It is aligned with the attribute semantics of the majority of C=0A=
family languages=0A=
=0A=
Best regards,  =0A=
Theodore=