Re: [RFC] [Discussion] Shorter Attribute Syntax Change

On Tue, July 28, 2020 at 9:46 AM Joe Ferguson <joe@joeferguson.me> wrote: > Hello Internals, > > I've been working with Derick Rethans and others (thanks all!) on a Shorter > Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax > would be preferred over the currently agreed upon "@@" syntax for Shorter > Attribute Syntax. > > An important part of the research that went into this proposal demonstrates > how "@@" will make handling attributes more difficult for PHP_CodeSniffer > (and similar tools) and shows how the alternative "#[]" syntax is more > friendly for these tools. > > You can find the RFC > https://wiki.php.net/rfc/shorter_attribute_syntax_change and > I'm happy to > answer any questions as best I can. Hi Joe, From the perspective of looks alone I don't care much one way or the other between @@ and #[]. However, I don't find the arguments for #[] in this RFC very compelling, and it ignores some of the other downsides of #[] compared to @@ that should be highlighted. Let's go through the arguments from the RFC: > It [@@] currently causes a parser conflict This isn't true now that namespaced names are treated as tokens. The @@ implementation has been merged into php-src and there is no parser conflict. > Various luminaires [sic] consider @@ a joke Who does this refer to? A random Reddit user? > Feedback to Derick's tweet (https://twitter.com/derickr/status/1285912223639130114) > were [sic] overwhelmingly positive Are you sure? I took a look at the thread and it seems like the responses were pretty mixed. Some people expressed support for #[], but almost as many were happier with the @@ syntax. If anything the majority of responses were neutral or expressing dislike for all the syntax options. > It has the distinct possibility to cause further parsing issues Like what? How is it any more likely to cause parsing issues than the @ syntax used by the majority of other C family languages? > Having a closing ] makes it easier to extend Attributes with more syntax This might be a good argument if there were actually a need to extend attributes with more syntax. What other languages have found a need for this? Even Rust doesn't allow additional syntax inside the brackets. > There is no “end symbol” to make finding occurrences easier, > including by reading or using regular expressions. Can you provide an example? When reading code I personally don't find the ending bracket very helpful - my brain tends to parse it as the end of an array, not the end of an attribute. Even when using a regex to search code, the ending bracket doesn't seem very helpful since arrays can also be passed as attribute arguments. For example, to match this attribute the regex for @@ is actually simpler than the one for #[]: ```php # regex: /@@\w+\(.+\)/ @@Attr([1, 2]) # vs. # regex: /#\[\w+\(.+\)\]/ #[Attr([1, 2])] ``` > A syntax with a closing demarcation is much easier to back fill with > tools such as PHPCS. I'm not sure I understand this. What does it mean to "back fill" a syntax with PHPCS, and what does a closing demarcation have to do with it? As a user, I'd expect to have to update PHPCS to work with PHP 8 code - doesn't it have to be updated anyway to correctly support the syntax for named arguments, union types, the nullsafe operator, match expression, etc.? And from a perspective of compatibility with existing tools, couldn't @@ be considered superior since people can use it in code examples on a blog without the syntax highlighter treating it as a comment? > It is a syntax no other language uses. Rust chose to use #[] even though it wasn't used by any other language. Does that make it a bad fit for Rust? No. But just because Rust uses a syntax also doesn't mean it's a good fit for PHP. @@ fits well with PHP since there is virtually no BC break, and the syntax is close to the @annotation syntax currently used in docblocks, so it's easily recognizable for what it is. On the other hand, #[] would be a larger BC break and can easily be confused for a comment. Best regards, Theodore