rfc:shorter_attribute_syntax_change

This is an old revision of the document!


PHP RFC: Shorter Attribute Syntax Change

Introduction

Based on the expressions of concern over using @@ for Shorter Attribute Syntax RFC https://wiki.php.net/rfc/shorter_attribute_syntax, I propose to use #[] instead. Please keep in mind that we want the best syntax, and not necessarily the best looking syntax.

Concerns with @@ are, with worked out reasons below:

  • It currently causes a parser conflict, which was not made clear in the original RFC.
  • Various luminaires consider @@ a joke, with some concerns expressed in https://www.reddit.com/r/PHP/comments/hjpu79/it_is/. Feedback to Derick's tweet ( https://twitter.com/derickr/status/1285912223639130114) were overwhelmingly positive, both public and private.
  • It has the distinct possibility to cause further parsing issues.
  • Having a closing ] makes it easier to extend Attributes with more syntax, and at the same time not be at the risk of running into parser conflicts.
  • There is no “end symbol” to make finding occurrences easier, including by reading or using regular expressions.
  • A syntax with a closing demarcation is much easier to back fill with tools such as PHPCS.
  • It is a syntax no other language uses.
  • The @ operator is not going to go away, so the possibility of @@ moving to @ is near to 0.

Note:

Proposal

We keep the Shorter Attribute Syntax RFC as is, except instead of implementing @@ as the syntax, we use the 2nd ranked vote winner #[].

While the Namespaced Names as Token RFC will resolve the parser conflicts mentioned above, another reason in favour of #[] has been raised by Mark Randall: https://externals.io/message/111101#111157 in which he describes the flexibility of closing tags offer for future development.

With << >> eliminated in the previous vote, only the Rust syntax of #[ ] allows us to proceed with confidence regarding the future extensibility of the syntax. By offering a clear opening and closing delimiter the parser will be better able to switch into processing attributes and attribute-specific modifiers without the need to look ahead to determine the end of the attribute statement, this is particularly true in terms of future compatibility where additional keywords may be added.

Upgrade Paths

Please read https://github.com/svpernova09/short-attr/issues/1#issuecomment-663240262

Upgrading to new PHP versions is import, with a closing demarcation, this becomes easier. From the linked comment it becomes clear that using #[ ] makes tooling through PHPCS and PHPCBF easier with #[ ] compared to << >> and @@, mostly because the attribute is left alone as it is regarded as a comment in PHP < 8.

The comment concludes with:

The take-away from this is that with both the first << >> as well as with the second syntax @@, the attribute is treated like normal code and fixed accordingly. This shouldn't happen as PSR12 has no rules about attributes or attribute formatting and therefore the attribute code should be left alone.

With the third syntax #[], the attribute is left alone as it is regarded as a comment in PHP < 8.

Of course, PHPCS will (attempt to) backfill the syntax for PHP < 8 once things are stabilized / gone into feature freeze, but we all know that people don't always upgrade as quickly as we'd want them too, so with the first two syntaxes, both PHPCS as well as external standards can expect a barrage of support requests/complaints/bug reports/tirades about code being fixed incorrectly from people who haven't upgraded to the PHPCS version with full PHP 8 support (presuming that's been released yet).

While with the third syntax, most sniffs, save for some comment sniffs will ignore the attribute and things will be (relatively) calm.

Backward Incompatible Changes

The #[] syntax will be a breaking change as currently # starts a line comment. After the implementation, ## only starts a comment when no followed by [.

The original choice is also breaking change, however, as currently @@ is the shut-up operator twice.

Proposed PHP Version(s)

PHP 8.0

Proposed Voting Choices

The vote will be to decide whether or not to accept #[] syntax instead of @@ for the Shorter Attribute Syntax RFC.

Patches and Tests

Implementation

After the project is implemented, this section should contain

  • the version(s) it was merged into
  • a link to the git commit(s)
  • a link to the PHP manual entry for the feature
  • a link to the language specification section (if any)

References

Links to external references, discussions or RFCs

rfc/shorter_attribute_syntax_change.1596407928.txt.gz · Last modified: 2020/08/02 22:38 by svpernova09