Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

This is only part of a thread. view whole thread
July 22, 2020 17:05 (Theodore Brown)
On Wed, July 22 2020 at 7:00 AM Derick Rethans <> 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 ( > - 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.
Hi Derick, 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 ( 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 helpful, either. 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. Best regards, Theodore