Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111558
To: Benjamin Eberlei <kontakt@beberlei.de>, Derick Rethans <derick@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Thread-Index: AQHWamWPHsqLR0j+3kKp37krfiTdR6k6jJOAgABPaVk=
Date: Sun, 16 Aug 2020 14:47:15 +0000
Message-ID:
 <DM6PR07MB66184A28DD625ED8C1899C5FF95E0@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>,<CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
In-Reply-To:
 <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [SNy55ZMnKYdt2jbPeJn1uPZzldtJO0HJ]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 3a73daa5-47be-4e19-7514-08d841f344b3
x-ms-traffictypediagnostic: BN8NAM12HT177:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 QsuQlpzk5IYjZ2qiPOdOi1zLJIoca1N/WzU8EEzDNpEQ87UqB2Bl7BMFaRUDlNIipfFzPJHtF0Z8dmiu5FJK4ty9SX7lyeS2GE1x4b9MKZV5FE54YaiZX40h9Cguhs/0tVObs8DXYLbBEG6qnBKbtu7xXRdq0Tyh351BsvUMFjVad3xIeKRy7XYBNS1YW0yZMZibqB0r/pyx9vyjpNbz0PA6gCFLspUKM4K4VG36R/8deebi0YtkdL9PDLkN6Akq
x-ms-exchange-antispam-messagedata:
 d4O/KEoujaMKpHJcCPeSrRjjIuJq3lL4qCdEDLUDKcTN/K8n5zZO5LMCbzXWN4QC3xcIkDGR6A53fhOpdU3twt81ny7DH8L9BHy3k8J2/PS7mV240kwBy+3hjLJiBz6nuTSuw1LdnVZQwWFmeqomTg==
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: BN8NAM12FT034.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a73daa5-47be-4e19-7514-08d841f344b3
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2020 14:47:15.7855
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM12HT177
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: tysonandre775@hotmail.com (tyson andre)

Hi Benjamin,=0A=
=0A=
> We are looking for further feedback from the community.=0A=
=0A=
Thanks, the updated RFC looks much better.=0A=
Some more feedback on why the edge cases are a concern to me,=0A=
and why the lack of an ending delimiter is similar to parsing problems alre=
ady faced.=0A=
=0A=
I'd agree that restarting a two-week discussion period seems excessive, and=
 a shorter one is fine with me.=0A=
=0A=
----=0A=
=0A=
The references section should probably also link to the other 2 RFC discuss=
ion threads=0A=
https://externals.io/message/111416 and the RFC discussion thread https://e=
xternals.io/message/111218=0A=
=0A=
----=0A=
=0A=
Developers who are new to PHP (e.g. learning by example) or those who spend=
 most of their time programming in other languages such as Rust or Java or =
Golang=0A=
might forget/not know that `#` is a supported line comment syntax, or that =
attributes were introduced in 8.0 (not an earlier release).=0A=
They might see that code using these edge cases passes syntax checks in PHP=
 7.4 and 8.0, and assume it'd work the same way in both versions, leading t=
o published code incorrectly marked as compatible with PHP 7.4.=0A=
=0A=
- PHP doesn't warn about calling a user-defined function too many parameter=
s, making this harder to detect.=0A=
=0A=
----=0A=
=0A=
The `#[]` syntax makes it possible and convenient to use attributes syntax,=
=0A=
but causes various problems for end users of code using attributes syntax.=
=0A=
I'd expect the drawbacks of bugs caused by edge cases such =0A=
as those in https://wiki.php.net/rfc/shorter_attribute_syntax_change#discus=
sion_of_forwards_compatibility_procons=0A=
to outweigh the benefits of being able to release attributes immediately.=
=0A=
=0A=
Putting attributes on the same line as parameters or closures or anonymous =
classes seems natural to do to me,=0A=
and I'd expect releases would do it eventually, whether it be immediately i=
n 8.0, years from now, etc.=0A=
=0A=
Suppose that package `A/A` supports PHP `7.4|^8.0`.=0A=
It depends on a package `B/B` 2.0 which supports PHP 7.4.=0A=
`B/B` depends on `C/C` `^4.0|^5.0`, where C/C 4.x supports PHP 7 =0A=
and C/C 5.0 drops support for PHP 7.=0A=
C/C 5.x uses attribute syntax on the same line as other code,=0A=
including several edge cases with one-line attributes that parse differentl=
y in php 7.0.=0A=
=0A=
```=0A=
    public function doDbMaintenance(=0A=
	#[MyUnused] bool $log =3D false,  // unused in db backend=0A=
	bool $doPotentiallyDestructiveUpdate =3D false,=0A=
	mixed $extraFlags =3D null,=0A=
    ) {...}=0A=
=0A=
// B/B calls doDbMaintenance($log =3D true)=0A=
```=0A=
=0A=
Then suppose that a maintainer or third-party packager (e.g. for a Linux di=
stro) of `A/A` =0A=
runs composer install with PHP 8.0 before building a package such as a phar=
, rpm, or tarball=0A=
(or `vendor/` checked into git) from `A/A` 1.0. =0A=
They would pull in B/B 2.0 and C/C 5.0, creating a release of A/A that was =
buggy =0A=
but did not emit any parse, compilation, or runtime warnings if end users r=
an that release with php 7.4.=0A=
=0A=
Then the maintainers of `A/A` and `C/C` 5.0 would get bug reports for PHP 7=
.4 for mysterious behaviors with no warnings,=0A=
which would be hard to reproduce and debug, despite all involved packages c=
orrectly specifying their dependencies.=0A=
End users would also be inconvenienced by bugs that had no obvious indicati=
on or subtler symptoms that may take a long time to get reported.=0A=
=0A=
This could be worked around by =0A=
=0A=
1. Setting `{"config": {"platform": {"php": "7.4.9"}}}` in composer.json of=
 A/A,=0A=
   or by documenting that `composer install` should always be run with PHP =
7.4,=0A=
   but I wouldn't expect new composer users to be aware of the ability to d=
o that =0A=
   until they run into issues, and that doesn't help if A/A is a dependency=
 of another package.=0A=
=0A=
2. C/C 5.0 could exit() when bootstrapping when it's run in php 7,=0A=
   but that seems excessive and not currently done by libraries in my exper=
ience.=0A=
=0A=
----=0A=
=0A=
If a developer needs to backport code or patches for php 8.0+ to php 7.4 or=
 older=0A=
(e.g. to support legacy applications or OSes that make updating php impract=
ical),=0A=
the lack of a syntax error would make this backporting error prone=0A=
if the developer didn't remember this incompatibility=0A=
or learn about tools created to catch issues.=0A=
(or didn't know about *up-to-date, bug-free* tools to downgrade php syntax)=
=0A=
=0A=
----=0A=
=0A=
For https://wiki.php.net/rfc/shorter_attribute_syntax_change#machine_scanni=
ng_for_end_of_attribute_declaration=0A=
I'd agree that the lack of an ending delimiter makes token-based extraction=
 more complicated but still practical,=0A=
but it is a complexity that projects such as phpcs **would already face in =
similar syntaxes.**=0A=
The problems with whitespace and comments and doc comments between tokens c=
an be fixed by filtering out whitespace and comments before/while looking t=
o the end of a token.=0A=
Projects such as nikic/php-parser or microsoft/tolerant-php-parser would be=
 what I'd recommend for new code/scripts,=0A=
but this is impractical for large existing codebases with third party plugi=
ns such as phpcs.=0A=
=0A=
A stack-based approach is used for `@[` or `#[`.=0A=
A stack-based approach would also be used for `@@Attribute /*comment */ (` =
by skipping T_WHITESPACE, T_COMMENT, and T_DOC_COMMENT and ending parsing o=
f that attribute if the next token isn't `(`.=0A=
Skipping whitespace and comments that way already needs to be done to **cor=
rectly** find the end of the function call `myGlobalFunction /* comment */ =
(args);` (or `new MyClass /* comment */ (args)`).=0A=
For both function calls and attributes, I'd assume style guides would forbi=
d whitespace and comments before `(`.=0A=
=0A=
Thanks,=0A=
- Tyson=