Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111239
To: Joe Ferguson <joe@joeferguson.me>, PHP Developers Mailing List
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Thread-Index: AQHWZO4I0QL2FiMxn0qlAoSLzTT8dakdpGAp
Date: Wed, 29 Jul 2020 00:21:31 +0000
Message-ID:
 <DM6PR07MB6618D517822A4EFDF0DEE1F1F9730@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
In-Reply-To:
 <CABj1Babv0bZyeNYBBOCZwG92NCT722G_tRt+hHZFxu4dHZckqw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [UTLo+KDEVbkO5bgetyFADWf1CZHIIYkNErTtM/9qYJ5rN+9DfKbI7Jltyh3zVU8r]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 2e3ce689-b7ba-44a0-5878-08d833555800
x-ms-traffictypediagnostic: BN7NAM10HT064:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 rt+7PbL8FHgb+PHjcDvBvLHUtgKJp1G+UawrHMswwhJan2lfMp/0PgRq6ANKDnMju1NTEdSvIv3yZOYonKEK/jvIQA1lK3i81zowSNBye4riJ2N2DV1LsNPvHSpc6Ykw+mDjZ8UvmPfzn1PoXLIFfZUOSfCcBtROVc5RKKikyUaOQ8mmPNcPJoVVxhfuOFeC9ccYtEo8RRgwLzczRH2WXebyVdTjBH+bCzxm2oOLriaocY9VPHbinEj77d/B411x
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR07MB6618.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 zPpyxOr72H3ft0rSkM2vEOLnyqIkWSLP8v0v8QiDxz1ptnh+5NRkQtS1zYELZ5DHcMnih0gPHQytJqAQswDYhjPhYZm6ngMG8G0CMvuUY1TEiqeb1VnqhJzCNRBsyyvRNQUmgHL7cBWgTFIDXs8SRNuygwdJcHvugqkIAnLxyYfGh3gHLAs5QygeXuaBfbSUlsUnNnhh/az1y0DigQ9Ipw==
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: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: BN7NAM10FT054.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e3ce689-b7ba-44a0-5878-08d833555800
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 00:21:31.3730
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7NAM10HT064
Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
For #[, my main objection is the various ways this can change the lexing in=
 a way that is impractical to (efficiently) backfill,=0A=
and that the proposed patch doesn't address the fact that the syntax may ch=
ange the syntax of php 7 code in unexpected ways. =0A=
=0A=
This syntax would help phpcs with easy examples **in the short term**, when=
 attributes are on a single line,=0A=
but would make more complicated refactorings buggy and error-prone unless p=
hpcbf was run in the same major version.=0A=
When attributes span multiple lines, the lexing is completely different for=
 `#[]`.=0A=
For example, the below syntax would yield false in php 7, but a generator i=
n php 8.=0A=
(There's precedent at least - the lexing of heredocs changed in php 7.3 or =
7.4)=0A=
=0A=
```=0A=
// Aside: This code snippet seems to have an assert failure in the lexer wi=
th the patch in the RFC=0A=
// Zend/zend_compile.c:1794: zendlex: Assertion `!(executor_globals.excepti=
on) || ret =3D=3D T_ERROR' failed.=0A=
function generator() {=0A=
=A0 =A0 yield #[MyCustomAttribute('=0A=
=A0 =A0 =A0 =A0 false;=0A=
=A0 =A0 =A0 =A0 // ']function() {};=0A=
}=0A=
```=0A=
=0A=
And another example which would cause problems for phpcs in php 7 - the com=
ment syntax can cause code to be treated as inline html instead of php toke=
ns.=0A=
=0A=
```=0A=
<?php=0A=
// This example echoes the rest of the source code in php 7=0A=
// and echoes "Test" in php 8.=0A=
#[DeprecationReason('reason: <https://some-website/reason?>')]=0A=
function main() {}=0A=
const APP_SECRET =3D 'app-secret';=0A=
echo "Test\n";=0A=
```=0A=
=0A=
I'd posted another example in=A0https://externals.io/message/111101#111133=
=0A=
=0A=
One way I'd thought of to avoid this ambiguity would be to assert in PHP 8.=
0 with an E_COMPILE_ERROR (or E_COMPILE_WARNING) that:=0A=
1. All tokens of the #[...] annotation are on the same line=0A=
2. No non-whitespace token follows the ] on the same line.=0A=
    It may be permissible to allow other `//` comments or multiple attribut=
es after it on the same line, though.=0A=
3. No `?>` substrings within the rest of the line after #[, maybe=0A=
=0A=
Although I'm not sure if others are actually concerned about this ambiguity=
 and these are really artificial examples for code.=0A=
=0A=
As for `<<`, I'm assuming people may have meant `yield <<JIT>> function() {=
};`,=0A=
but `yield` already has a precedence and didn't have issues - otherwise `yi=
eld+2;`  could be adding 2 to the result of a yield.=0A=
(It's unambiguously `yield(+2);` right now).=0A=
I forget how it'd be parsed, but it wouldn't be ambiguous.=0A=
=0A=
As for `@@`, all of its known issues seem to have been resolved,=0A=
and there is still the potential for future issues, but I still prefer it o=
ver the `#[` implementation in that patch.=0A=
=0A=
P.S. I'd like to note that=0A=
1. A lot more discussion has occurred since the initial vote.=0A=
2. Since `@@` was obviously passing at the time, fewer voters would put muc=
h thought into detailed tradeoffs of `#[`=0A=
3. I haven't seen those specific drawbacks to `#[` of potentially significa=
ntly changing lexing (not just losing tokens) mentioned,=0A=
   but the shorter attributes syntax RFC did seem to mention params were co=
mmented out.=0A=
=0A=
One idea I'd have on voting would be to have the exact same 3-way vote, aga=
in, and pick the attribute syntax with the same ranked choice procedure.=0A=
I assume proponents of `#[` would have similar objections if an RFC with a =
two-way vote for  `<<>>` and `@@` was started first.=0A=
=0A=
Regards,=0A=
- Tyson=