Re: [RFC] Shorter Attribute Syntax Change RFC 0.2
| From: | tyson andre | Date: | Wed, 05 Aug 2020 01:57:37 +0000 |
| Subject: | Re: [RFC] Shorter Attribute Syntax Change RFC 0.2 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-111334@lists.php.net to get a copy of this message | ||
Hi Derick,
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
1. I feel like "Changes the lexing of **remaining** tokens" should also be included in the
table following it - that's a major difference between
#[(Yes) and each of the
other proposals (No).
The last time a substantial lexing change (that affected the following tokens, not just the
tokens in question) happened was https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
, but flexible heredoc is rare in practice and a project using it would almost always need to drop
support for 7.2.
I expect attributes to be used much, much more frequently than flexible heredoc, and to break in
subtler ways.
Projects such as php-parser would be affected by the change to lexing, and would either have to
force users to specify the php major version or to always emulate 8.0's lexing if
#[ was encountered in a T_COMMENT token.
My earlier objections to #[ were https://externals.io/message/111218#111239
To add to that, the benefit of forwards compatibility is also a drawback in some ways for the
next few years (or longer, if you include OSes that unofficially backport security patches)
A developer running php7 could run php --syntax-check locally on a file containing
attributes
and assume it'd work in php 8 when deployed to a php 8 environment or when publishing a
library to packagist.
(e.g. #[DeprecationReason('This won't work because X')] has a single
quote after won terminating a string literal, resulting in a parse error only affecting
php 8)
Better tooling would help to avoid that, but better tooling isn't universal.
2. This RFC mentions objections to @@ but not objections to other syntaxes.
Summarizing/Linking the main arguments for/against all 4+ proposed syntaxes in an appendix of
the RFC (with some reasonable length limit) would help in making an informed vote.
There have been over 50 emails so far in https://externals.io/message/111300 and https://externals.io/message/111312
Thanks,
- Tyson