The @@ is terrible, are we sure we're OK with it?

  111101
July 22, 2020 12:00 derick@php.net (Derick Rethans)
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
July 22, 2020 12:10 ocramius@gmail.com (Marco Pivetta)
<http://ocramius.github.com/>


On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans <derick@php.net> wrote:

> 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
July 22, 2020 12:18 sebastian@php.net (Sebastian Bergmann)
Am 22.07.2020 um 14:00 schrieb Derick Rethans:
> Please, let's do the sensible and use the Rusty #[...] syntax.
+1
  111104
July 22, 2020 12:28 benas.molis.iml@gmail.com (Benas IML)
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.

On Wed, Jul 22, 2020, 3:00 PM Derick Rethans <derick@php.net> wrote:

> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  111105
July 22, 2020 12:30 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)
Hi Derick,

śr., 22 lip 2020 o 14:00 Derick Rethans <derick@php.net> 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
July 22, 2020 12:39 deleugyn@gmail.com (Deleu)
"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.

On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans <derick@php.net> wrote:

> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
-- Marco Aurélio Deleu
  111108
July 22, 2020 12:44 kjarli@gmail.com (Lynn)
On Wed, Jul 22, 2020 at 2:39 PM Deleu <deleugyn@gmail.com> wrote:

> "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
July 22, 2020 12:46 kontakt@beberlei.de (Benjamin Eberlei)
On Wed, Jul 22, 2020 at 2:40 PM Deleu <deleugyn@gmail.com> wrote:

> "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.
> On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans <derick@php.net> wrote: > > > 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 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > > -- > Marco Aurélio Deleu >
  111111
July 22, 2020 12:49 brendt@stitcher.io (Brent Roose)
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

> On 22 Jul 2020, at 14:46, Benjamin Eberlei <kontakt@beberlei.de> wrote: > > On Wed, Jul 22, 2020 at 2:40 PM Deleu <deleugyn@gmail.com> wrote: > >> "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. > > >> On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans <derick@php.net> wrote: >> >>> 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 >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: https://www.php.net/unsub.php >>> >>> >> >> -- >> Marco Aurélio Deleu >>
  111113
July 22, 2020 12:58 larry@garfieldtech.com ("Larry Garfield")
On Wed, Jul 22, 2020, at 7:49 AM, Brent Roose wrote:
> 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
  111110
July 22, 2020 12:47 george.banyard@gmail.com ("G. P. B.")
On Wed, 22 Jul 2020 at 13:39, Deleu <deleugyn@gmail.com> wrote:

> "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
  111107
July 22, 2020 12:44 bukka@php.net (Jakub Zelenka)
Hi,

On Wed, Jul 22, 2020 at 1:00 PM Derick Rethans <derick@php.net> wrote:

> 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
  111115
July 22, 2020 13:58 come.chilliet@fusiondirectory.org (=?UTF-8?B?Q8O0bWU=?= Chilliet)
Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
Derick Rethans <derick@php.net> 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
  111117
July 22, 2020 14:07 david.proweb@gmail.com (David Rodrigues)
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 <derick@php.net> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  111116
July 22, 2020 14:06 daniel.spiridione@gmail.com (=?UTF-8?Q?Daniel_Mart=C3=ADn_Spiridione?=)
+1

El mié., 22 jul. 2020 a las 9:00, Derick Rethans (<derick@php.net>)
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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  111119
July 22, 2020 14:16 marandall@php.net (Mark Randall)
On 22/07/2020 13:00, Derick Rethans wrote:
> 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
July 22, 2020 14:37 carusogabriel@php.net (Gabriel Caruso)
On Wed, 22 Jul 2020 at 14:00, Derick Rethans <derick@php.net> wrote:

> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > 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
July 22, 2020 14:45 joe@joeferguson.me (Joe Ferguson)
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 <carusogabriel@php.net>
wrote:

> On Wed, 22 Jul 2020 at 14:00, Derick Rethans <derick@php.net> wrote: > > > 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 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > 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 >
-- - Joe Ferguson JoeFerguson.me osmihelp.org
  111124
July 22, 2020 14:48 sebastian@php.net (Sebastian Bergmann)
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
July 22, 2020 16:43 d.h.j.takken@freedom.nl (Dik Takken)
On 22-07-2020 16:45, Joe Ferguson wrote:
> 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
July 22, 2020 16:49 marandall@php.net (Mark Randall)
On 22/07/2020 17:43, Dik Takken wrote:
> 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
July 22, 2020 16:51 derick@php.net (Derick Rethans)
On Wed, 22 Jul 2020, Dik Takken wrote:

> 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
  111135
July 22, 2020 19:24 d.h.j.takken@freedom.nl (Dik Takken)
On 22-07-2020 18:51, Derick Rethans wrote:
> 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
  111132
July 22, 2020 17:05 theodorejb@outlook.com (Theodore Brown)
On Wed, July 22 2020 at 7:00 AM Derick Rethans <derick@php.net> 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 > 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
July 22, 2020 17:09 tysonandre775@hotmail.com (tyson andre)
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
  111140
July 22, 2020 23:14 nesk@xakep.ru (=?UTF-8?B?0JrQuNGA0LjQu9C7INCd0LXRgdC80LXRj9C90L7Qsg==?=)
However this syntax allows it to be used on 7.4 unlike any other.
 
This means that the initial transition of library functionality to it will be very smooth and will not require a separate implementation of polyfills for the syntax of doctrine annotations and attributes.
 
With any other syntax, this would require implementing 3 separate attribute classes and a bootstrap for them:
 
```
/** @Annotation */
class MyAttribute extends BaseAttribute {}
 
/** @Annotation */
@@\Attribute
class MyAttribute extends BaseAttribute {}
 
abstract class BaseAttribute {}
 
// and bootstrap
 
if (version_compare(PHP_VERSION, ‘8.0’) >= 0) {
    require __DIR__ . ‘/polyfill/MyAttribute.php’;
}
```
 
For Rust-like `#[xxx]` nothing of this is required.
  
>Среда, 22 июля 2020, 20:09 +03:00 от tyson andre <tysonandre775@hotmail.com>: >  >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 >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: https://www.php.net/unsub.php >   
  -- Kirill Nesmeyanov  
  111145
July 23, 2020 07:37 php@beccati.com (Matteo Beccati)
Hi,

On 22/07/2020 19:09, tyson andre wrote:
> 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.
This is pretty much the reason why I didn't go for '#[' as my first choice: the false sense of backwards compatibility that can be easily (and inadvertently) defeated with multiline attributes or inline function definition. Since '@@' is causing such unrest, I'd be happy to revisit my choice and embrace '#[', which was the second option in my vote. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/
  111136
July 22, 2020 19:51 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea?
I think it's not a very good idea, and <<>> was just fine, but a lot of folks apparently voted for it. Would be nice to see their opinion and how they answer your concerns. I'm not sure it's proper to override the vote unless there are some severe technical concerns that make that choice impossible. -- Stas Malyshev smalyshev@gmail.com
  111138
July 22, 2020 21:29 pollita@php.net (Sara Golemon)
On Wed, Jul 22, 2020 at 7:00 AM Derick Rethans <derick@php.net> wrote:

> I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > Yes. Because we voted on it. Twice.
> - 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
Citation Needed. The '@' token and the T_DOUBLE_AT token come from the lexer as distinct values, where is the conflict? I'm not doubting that there is one, you're quite clever, but at the moment you're stating facts not currently in evidence.
> - 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. > > We knew each of these points at the time of voting. This is not new information.
> Please, let's do the sensible and use the Rusty #[...] syntax. > > Remoaner. (j/k, you know I love you)
I'm fine with this or any syntax, but FF is 13 days away, you're going to have to give me something more substantial than "It maybe breaks something somewhere somehow". -Sara
  111141
July 23, 2020 01:00 pollita@php.net (Sara Golemon)
On Wed, Jul 22, 2020 at 4:29 PM Sara Golemon <pollita@php.net> wrote:

> Citation Needed. > > The '@' token and the T_DOUBLE_AT token come from the lexer as distinct > values, where is the conflict? > > I'm not doubting that there is one, you're quite clever, but at the moment > you're stating facts not currently in evidence. > > So evidently, this is specifically an issue with attributes in places where
a portion of their name could be mistaken for a type. AIUI, that's being addressed. So the complaint is "what if moar ambiguity?" ? Seems like we're trading a lot of ambiguities. @@ might be a double error suppress (and might spill over types) #[..] might be a legit comment <<...>> might be a freaky combination of bit shifts Regards the vote; I don't believe that @@ has been proven unworkable, however if I'm wrong about that, then the second choice selection from the last vote would obviously take precedence. -Sara
  111143
July 23, 2020 06:26 marandall@php.net (Mark Randall)
On 23/07/2020 02:00, Sara Golemon wrote:
> Regards the vote; I don't believe that @@ has been proven unworkable, > however if I'm wrong about that, then the second choice selection from the > last vote would obviously take precedence.
I don't believe the concern is that we have something unworkable sitting in front of us right now, after all if that were the case we would not be needing to have this conversation as the RFC would already have been rendered void. What we do have, is a deep sense of unease that we collectively made the wrong decision, based on, in part, incomplete information. While the initial block to @@ has been remedied by a larger language-level change, that the problem existed at all provided a clear example of the widely unforeseen challenges associated with the @@ syntax and its lack of closing tags, and focused renewed attention on long-term consequences which where perhaps not given enough consideration during the vote. There has been one occurrence already, there will likely be more in the future. But what specifically will they be and how severe? We likely will not know until they happen. But what we can say with reasonable confidence is we have an option on the table that is technically superior, has an implementation ready to go, and that will significantly allay the fears of many in internals who feel that the @@attributes syntax poses an unnecessary risk of burdening future development. Lets' not commit ourselves to 20+ years of supporting a syntax that we already have strong reservations about before it's even out the door. Mark Randall marandall@php.net
  111157
July 23, 2020 16:36 marandall@php.net (Mark Randall)
On 22/07/2020 13:00, Derick Rethans wrote:
> - 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/)
From discussions in R11 I want to offer the following example of why either option with a closing tag is preferable to allow maximum flexibility in future development. Assume we want to extend attributes to include something a lot of PHP features have, an access scope, to only allow accessing annotations from within the class itself, or a descendant. Then we end up with something like : class Foo { @@protected Attr protected int $bar; } Contrast that to something with opening and closing tags where they are clearly grouped: class Foo { #[protected Attr] protected int $bar; } What other syntax might we want to add? Perhaps we want to add a way to enforce validation at encounter time with a "checked" keyword. @@checked protected Attr(1,2,3) protected int $bar #[checked protected Attr(1,2,3)] protected int $bar It's much less ambiguous what belongs to what. Now we could dig ourselves out of this hole using additional tokens around @@ such as @@(checked protected Attr) but at which point why not just use a mechanism that supports it out of the box? Mark Randall