# The @@ is terrible, are we sure we're OK with it?
- Thread: https://externals.io/message/111101
- Original archive: https://news-web.php.net/php.internals/111101
- Started by Derick Rethans on 2020-07-22T12:00:10+00:00
- Messages: 42
- RFC: Shorter Attribute Syntax Change (Implemented (PHP 8.0)) — https://externals.io/rfc/shorter_attribute_syntax_change.md
- RFC: Treat namespaced names as single token (Implemented (PHP 8.0)) — https://externals.io/rfc/namespaced_names_as_token.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/111101.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #111101 — Derick Rethans — 2020-07-22T12:00:10+00:00
URL: https://externals.io/message/111101#111101
Hi all,
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
https://wiki.php.net/rfc/namespaced_names_as_token
- 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.
cheers,
Derick
--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug
---
## #111102 — Marco Pivetta — 2020-07-22T12:10:08+00:00
URL: https://externals.io/message/111101#111102 · In reply to: #111101
> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
Pretty much clear that @@ is a bad choice - it was picked due to
familiarity of some folks with java annotations,
but it is clear that rust-ish annotations with a clear delimiter have
technical advantages in parsing and future scope/support.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
---
## #111103 — Sebastian Bergmann — 2020-07-22T12:18:40+00:00
URL: https://externals.io/message/111101#111103 · In reply to: #111101
Am 22.07.2020 um 14:00 schrieb Derick Rethans:
> Please, let's do the sensible and use the Rusty #[...] syntax.
+1
---
## #111104 — Benas IML — 2020-07-22T12:28:19+00:00
URL: https://externals.io/message/111101#111104 · In reply to: #111101
Also, +1. I don't really care whether we switch back to `<<...>>` or
`#[...]` but I think `@@` was a bad choice and thus, I think it would be a
much more sensible decision to change the syntax again. At least for the
sake of not running into new ambiguities and in order to stay more similar
with other languages.
> Hi all,
>
> 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
> https://wiki.php.net/rfc/namespaced_names_as_token
> - 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.
>
> cheers,
> Derick
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
>
> To unsubscribe, visit: https://www.php.net/unsub.php
---
## #111105 — michal.brzuchalski@gmail.com — 2020-07-22T12:30:29+00:00
URL: https://externals.io/message/111101#111105 · In reply to: #111101
Hi Derick,
śr., 22 lip 2020 o 14:00 Derick Rethans napisał(a):
> Hi all,
>
> 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
> https://wiki.php.net/rfc/namespaced_names_as_token
> - 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.
>
I agree with all the above arguments.
Is there a place (before feature-freeze) and a way to revote it?
What should be the procedure then?
Does it mean the RFC process has an issue and how could it be fixed?
Cheers,
Michał
---
## #111106 — Deleu — 2020-07-22T12:39:09+00:00
URL: https://externals.io/message/111101#111106 · In reply to: #111101
"Terrible" is the amount of humans having their lives taken by a pandemic.
This is at most slightly inconvenient for you. The aggressive tone in this
discussion is extremely unnecessary.
> Hi all,
>
> 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
> https://wiki.php.net/rfc/namespaced_names_as_token
> - 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.
>
> cheers,
> Derick
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
>
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
---
## #111107 — Jakub Zelenka — 2020-07-22T12:44:21+00:00
URL: https://externals.io/message/111101#111107 · In reply to: #111101
Hi,
> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
I agree that @@ is really bad. Personally I'd prefer <<...>> but #[...]
seems fine as well (although it's a minor BC break as there could be a
valid comment). I think there are more people that are fine with both
<<...>> and #[...] but don't like @@. Maybe having an option to vote for
more options would be more suitable here or something where it's possible
to vote against @@ rather than just pick one option.
Cheers
Jakub
---
## #111108 — Lynn — 2020-07-22T12:44:23+00:00
URL: https://externals.io/message/111101#111108 · In reply to: #111106
> "Terrible" is the amount of humans having their lives taken by a pandemic.
> This is at most slightly inconvenient for you. The aggressive tone in this
> discussion is extremely unnecessary.
>
Hi,
If you want to get nitpicky about the definition:
adjective: *terrible*
1. 1.
extremely bad or serious.
"a terrible crime"
I agree with the above posters that @@ for annotations is a terrible
syntax. My choice (if I could vote) would also be the rust variant.
Regards,
Lynn
---
## #111109 — Benjamin Eberlei — 2020-07-22T12:46:48+00:00
URL: https://externals.io/message/111101#111109 · In reply to: #111106
> "Terrible" is the amount of humans having their lives taken by a pandemic.
> This is at most slightly inconvenient for you. The aggressive tone in this
> discussion is extremely unnecessary.
>
After the RFC was voted on for @@, objectively "terrible" (or bad) reasons
for this patch have been found though, that can only be softened by
changing token parsing for namespaces.
This is not a subjective opinion.
>
>
> > […]
>
> --
> Marco Aurélio Deleu
---
## #111110 — G. P. B. — 2020-07-22T12:47:31+00:00
URL: https://externals.io/message/111101#111110 · In reply to: #111106
> "Terrible" is the amount of humans having their lives taken by a pandemic.
> This is at most slightly inconvenient for you. The aggressive tone in this
> discussion is extremely unnecessary.
>
When the voted syntax is technically infeasible due to parser issues
which can only be resolved by another RFC, albeit a sensible one,
I would say this is indeed a terrible choice.
I personally prefer <<...>> but I can accept Rust's syntax more easily
than @@ which seems to come from a preconception that it will
transition to @ many moons in the future which is completely bonkers.
Best regards
George P. Banyard
---
## #111111 — Brent Roose — 2020-07-22T12:49:48+00:00
URL: https://externals.io/message/111101#111111 · In reply to: #111109
Doesn't it make the most sense to re-vote the syntax? I'd consider the previous vote to be invalid given the parsing issues that weren't listed in the RFC.
A re-vote seems the most fair: if the majority still prefers @@, then so be it. Otherwise the syntax changes once again, before feature-freeze. I suppose the RMs should have a final say in this descision?
Kind regards
Brent
>
>
>
>
> > […]
>
> After the RFC was voted on for @@, objectively "terrible" (or bad) reasons
> for this patch have been found though, that can only be softened by
> changing token parsing for namespaces.
>
> This is not a subjective opinion.
>
>
> > […]
---
## #111113 — Larry Garfield — 2020-07-22T12:58:05+00:00
URL: https://externals.io/message/111101#111113 · In reply to: #111111
> Doesn't it make the most sense to re-vote the syntax? I'd consider the
> previous vote to be invalid given the parsing issues that weren't
> listed in the RFC.
>
> A re-vote seems the most fair: if the majority still prefers @@, then
> so be it. Otherwise the syntax changes once again, before
> feature-freeze. I suppose the RMs should have a final say in this
> descision?
>
> Kind regards
> Brent
One of the advantages of having conducted it as a ranked-choice-vote is that we can easily disqualify the @@ option and then recount with just the other two, counting @@ supporters' second choice. No new vote is needed, unless we think a significant number of people would have changed their minds between << >> and #[ ] since then. (I think that's unlikely, personally.)
IIRC, it looked like #[ ] would win that runoff but it's easy enough to recompute and be sure.
I agree this is ultimately an RM decision for how to proceed; my recommendation would be to Make A Call(tm) if the parsing issues of @@ are significant enough to disqualify it, and if so, recompute the vote as above and go with the result.
@@ may be easier to type than the others, but at the end of the day the parsing problems it introduces seem like the killer blow to me.
--Larry Garfield
---
## #111115 — come.chilliet@fusiondirectory.org — 2020-07-22T13:58:11+00:00
URL: https://externals.io/message/111101#111115 · In reply to: #111101
Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
Derick Rethans a écrit :
> Please, let's do the sensible and use the Rusty #[...] syntax.
This syntax is the one I liked the less in the proposed choices, given # is
used for comments.
Wouldn’t #[] cause more parsing issues than @@?
What would be the rule, it’d be illegal to start a comment content with '['?
Côme
---
## #111116 — daniel.spiridione@gmail.com — 2020-07-22T14:06:39+00:00
URL: https://externals.io/message/111101#111116 · In reply to: #111101
+1
El mié., 22 jul. 2020 a las 9:00, Derick Rethans ()
escribió:
> Hi all,
>
> 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
> https://wiki.php.net/rfc/namespaced_names_as_token
> - 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.
>
> cheers,
> Derick
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
>
> To unsubscribe, visit: https://www.php.net/unsub.php
---
## #111117 — David Rodrigues — 2020-07-22T14:07:21+00:00
URL: https://externals.io/message/111101#111117 · In reply to: #111115
My suggestion is the tilde (~). Currently is used only as the bitwise NOT
operator, but in this context seems to not have any problem.
~ Attribute1(~1)
~ Attribute2(...)
function withAttribute() { ... }
Or then we could use another more detailed syntax:
<-- Attribute(...), ... -->
:: Attribute(...), ...
Or even create a new keyword like:
with Attribute(...), ...
function withAttribute() { ... }
And in last case, just use nothing but the attribute itself as a prefix:
Attribute(...) function withAttribute() {...}
Atenciosamente,
David Rodrigues
Em qua., 22 de jul. de 2020 às 10:58, Côme Chilliet <
come.chilliet@fusiondirectory.org> escreveu:
> Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
> Derick Rethans a écrit :
> > […]
>
> This syntax is the one I liked the less in the proposed choices, given # is
> used for comments.
>
> Wouldn’t #[] cause more parsing issues than @@?
>
> What would be the rule, it’d be illegal to start a comment content with
> '['?
>
> Côme
>
> --
>
> To unsubscribe, visit: https://www.php.net/unsub.php
---
## #111119 — Mark Randall — 2020-07-22T14:16:51+00:00
URL: https://externals.io/message/111101#111119 · In reply to: #111101
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
No, no we are not.
We've already found one gaping hole in it, we will likely find more. Why
knowingly back ourselves into a corner when there are perfectly good
alternatives?
Mark Randall
marandall@php.net
---
## #111120 — Gabriel Caruso — 2020-07-22T14:37:34+00:00
URL: https://externals.io/message/111101#111120 · In reply to: #111101
> Hi all,
>
> 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
> https://wiki.php.net/rfc/namespaced_names_as_token
> - 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.
>
> cheers,
> Derick
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
>
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hello Derick.
I do understand your concerns, and I appreciate that you've reached out.
Although we are very close to the Feature Freeze date for PHP 8.0 (
https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for
this specific case and let you (or someone), create an RFC proposing to
change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2),
and that only!
I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as
well.
-- Gabriel Caruso
---
## #111122 — Joe Ferguson — 2020-07-22T14:45:35+00:00
URL: https://externals.io/message/111101#111122 · In reply to: #111120
Hello, Internals,
I would be happy to author an RFC on replacing @@ with #[] but based on
Larry's comments it sounds like the weighted voting already solved this
issue for us? We as internals just need to decide that @@ isn't a solution
and defer to the next ranked vote? I'd be the first one to +1.
On Wed, Jul 22, 2020 at 9:38 AM Gabriel Caruso
wrote:
>
>
> > […]
> Hello Derick.
>
> I do understand your concerns, and I appreciate that you've reached out.
>
> Although we are very close to the Feature Freeze date for PHP 8.0 (
> https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for
> this specific case and let you (or someone), create an RFC proposing to
> change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2),
> and that only!
>
> I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as
> well.
>
> -- Gabriel Caruso
>
--
- Joe Ferguson
JoeFerguson.me
osmihelp.org
---
## #111124 — Sebastian Bergmann — 2020-07-22T14:48:28+00:00
URL: https://externals.io/message/111101#111124 · In reply to: #111122
Am 22.07.2020 um 16:45 schrieb Joe Ferguson:
> We as internals just need to decide that @@ isn't a solution
> and defer to the next ranked vote? I'd be the first one to +1.
Makes sense to me; +1.
---
## #111128 — Dik Takken — 2020-07-22T16:43:48+00:00
URL: https://externals.io/message/111101#111128 · In reply to: #111122
> I would be happy to author an RFC on replacing @@ with #[] but based on
> Larry's comments it sounds like the weighted voting already solved this
> issue for us? We as internals just need to decide that @@ isn't a solution
> and defer to the next ranked vote? I'd be the first one to +1.
That means we effectively disregard the preferences of the ones who
voted for the @@ syntax. We do not know what the @@ voters would have
chosen if the choice was between << >> and #[]. In case the @@ voters
have a preference for << >> the result could turn out differently. The
only way to know is to take another vote.
Regards,
Dik Takken
---
## #111129 — Mark Randall — 2020-07-22T16:49:21+00:00
URL: https://externals.io/message/111101#111129 · In reply to: #111128
> That means we effectively disregard the preferences of the ones who
> voted for the @@ syntax. We do not know what the @@ voters would have
> chosen if the choice was between << >> and #[]. In case the @@ voters
> have a preference for << >> the result could turn out differently. The
> only way to know is to take another vote.
Yes we do - it was a ranked choice vote where voters selected their
first, second and third preferences.
If @@ is eliminated, the second choice of all those who voted for it as
their first choice is already known.
Mark Randall
---
## #111130 — Derick Rethans — 2020-07-22T16:51:40+00:00
URL: https://externals.io/message/111101#111130 · In reply to: #111128
> We do not know what the @@ voters would have chosen if the choice was
> between << >> and #[]. In case the @@ voters have a preference for
> <<>> the result could turn out differently. The only way to know is to
> take another vote.
This is something that STV is specifically designed to solve. You rank
in order by preference. And @@, <<>>, and #[] were all three options.
In your example, these people would have marked @@ as first, <<>> as
second, and #[] as third.
cheers,
Derick
---
## #111132 — Theodore Brown — 2020-07-22T17:05:49+00:00
URL: https://externals.io/message/111101#111132 · In reply to: #111101
> 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
> https://wiki.php.net/rfc/namespaced_names_as_token
> - 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 (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:
https://github.com/php/php-src/pull/5796.
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
---
## #111133 — tyson andre — 2020-07-22T17:09:42+00:00
URL: https://externals.io/message/111101#111133 · In reply to: #111101
Hi Derick,
> Please, let's do the sensible and use the Rusty #[...] syntax.
I'd probably re-vote for `<>` given the fact that `@@` may introduce similar parsing ambiguities in the future
that may interfere with future language changes. (but those issues are not a certainty)
I think that `#[` has its own issues, but am open to re-voting on it.
For example, the following snippet would get parsed differently in PHP 7.4 and PHP 8.0, given a hypothetical JIT annotation for Opcache.
With <>, it would give people a clear indication that the file required PHP 8.0,
but a one-line annotation might be silently treated differently in many subtle ways in 7.4.
It's probably possible to amend the parser make it an error to put the function declaration on the same line or to have other `#` comments
within a multi-line #[ annotation,
but I really dislike the special casing it would add.
```
$function = array_filter(
$values,
#[Opcache\Jit] function(int $x) { return $x % 2 > 0; }
);
```
Cheers,
- Tyson
---
## #111135 — Dik Takken — 2020-07-22T19:24:16+00:00
URL: https://externals.io/message/111101#111135 · In reply to: #111130
> This is something that STV is specifically designed to solve. You rank
> in order by preference. And @@, <<>>, and #[] were all three options.
>
> In your example, these people would have marked @@ as first, <<>> as
> second, and #[] as third.
Ah, that was not clear to me. My apologies for the noise.
Thanks,
Dik
---
Next page: https://externals.io/message/111101.md?page=2