On Wed, July 22 2020 at 7:00 AM Derick Rethans <email@example.com> wrote:
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
> - There are lots of grumbles, both on here, room 11, as well as in the
> wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
> - It has the distinct possibility to cause further parsing issues, akin
> to what ended up happening with what Nikita is addressing at
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
> also 0.
> Please, let's do the sensible and use the Rusty #[...] syntax.
Most of the comments in that Reddit thread appear to be positive or
neutral, and in the earlier community poll, the @@ syntax received by
far the most votes (https://www.reddit.com/r/PHP/comments/h06bra/community_poll_attribute_syntax/).
So while some in the community may prefer a different syntax, this
doesn't seem to reflect the majority.
If @@ actually has parsing issues, then I would agree that we need to
pick another syntax. But there aren't any issues following Nikita's
RFC to treat namespaced names as tokens. Please check out the
implementation and let me know if you find any problems:
While most would like to have a single @ character for attributes,
since this isn't possible @@ is the closest alternative, and it
shouldn't present any parsing issues that wouldn't also affect a
single @ character. Of course it will always be possible to think of
theoretical ambiguities with unconventional future syntax, but in
practice this hasn't been an issue for the many other languages using @.
One of the benefits of @@ is actually making it easier to find
occurrences. <<>> is problematic here since these characters also
occur in heredocs/nowdocs and bit shifts. And the ending bracket of
# is also used for arrays, so it's not clear that this is very
The benefit of # being exactly the same as another language was
considered in the Shorter Attribute Syntax RFC, but apparently most
voters didn't feel that this outweighed the downsides of a larger BC
break, extra verbosity, and possible confusion with comments.
If there isn't an actual technical problem with the implementation, I
don't think it would be appropriate to hold another vote, or discard
the first preference vote of all those who preferred the @@ syntax.