[RFC] [Discussion] Shorter Attribute Syntax Change

  111218
July 28, 2020 14:46 joe@joeferguson.me (Joe Ferguson)
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.

-- 
- Joe Ferguson
JoeFerguson.me
osmihelp.org
  111220
July 28, 2020 15:13 come.chilliet@fusiondirectory.org (=?UTF-8?B?Q8O0bWU=?= Chilliet)
Le Tue, 28 Jul 2020 09:46:38 -0500,
Joe Ferguson <joe@joeferguson.me> a écrit :

> 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. >
The text uses « instead of <<, it’s confusing. It should be made clearer what #[ ] has over << >>, which does not cause any BC break. Côme
  111221
July 28, 2020 15:25 ben@benramsey.com (Ben Ramsey)
> On Jul 28, 2020, at 10:13, Côme Chilliet chilliet@fusiondirectory.org> wrote: > > Le Tue, 28 Jul 2020 09:46:38 -0500, > Joe Ferguson <joe@joeferguson.me> a écrit : > >> 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. >> > > The text uses « instead of <<, it’s confusing. > > It should be made clearer what #[ ] has over << >>, which does not cause any BC > break. > > Côme
I don’t know that it’s valuable to spend time discussing advantages over `<< >>`. Isn’t it clear from the previous RFC[^1] that `@@` and `#[ ]` both won out over `<< >>`? Cheers, Ben [^1]: https://wiki.php.net/rfc/shorter_attribute_syntax
  111222
July 28, 2020 15:50 derick@php.net (Derick Rethans)
On Tue, 28 Jul 2020, Joe Ferguson wrote:

> 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.
This is an excellent RFC highlighting the important deficiencies of the @@ syntax. I hope you will all read this and also conclude that we can still pick this better syntax. Remember that it is not only about how it looks. It is much more important that it is functional and causes the least amount of friction in the community. 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
  111223
July 28, 2020 15:54 sebastian@php.net (Sebastian Bergmann)
Am 28.07.2020 um 17:50 schrieb Derick Rethans:
> This is an excellent RFC highlighting the important deficiencies of the > @@ syntax. > > I hope you will all read this and also conclude that we can still pick > this better syntax. > > Remember that it is not only about how it looks. It is much more > important that it is functional and causes the least amount of friction > in the community.
Hear, hear.
  111225
July 28, 2020 17:57 theodorejb@outlook.com (Theodore Brown)
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
  111227
July 28, 2020 18:55 pmjones@pmjones.io ("Paul M. Jones")
Hi all,

> On Jul 28, 2020, at 12:57, Theodore Brown <theodorejb@outlook.com> wrote: > >> On Tue, July 28, 2020 at 9:46 AM Joe Ferguson <joe@joeferguson.me> wrote: >> >> ... >> >> 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.
Let's count. + is "change away from @@ to anything else", - is "stay with @@", ? is hard-to-tell/weak/uncertain/they-all-suck. Derick Rethans: ++ Rafael Dohms: +? Alexander Berl: -? Chris Emerson: -- Tamas Erdelyi: ?? Phili Weinke: ?? Trent: ++ Juriaan Ruitenberg: ++ Mehran: ++ Stephan Hochdorfer: ?? Cees-Jan Kiewiet: ?? Tom Witkowski: ++ Matiss: ++ Henry Paradiz: -- Saif: ?? Paul Redmond: ?? Marco Pivetta: ++ Simon Champion: ?? @eimihar: ?? Brent: +? Graham Campbell: +? Dmitri Goosens: ++ Sergej Kurakin: -? Francis Lavoie: ?? Michael Moravec: ?? John Hunt: ?? Lars Moelleken: ?? Michal Brzuchalski: -? Kyrre: ?? Steve MacDougall: ++ Agustin Gomes: ?? Mike Rockett: ++ Matias Navarro: ++ Marisa Clardy: ++ Warp Speed: -- WJB: +? Martijn Minnis: -- Dennis de Best: ?? Damo: ?? SOFTonSOFA: +? Ashish K. Poudel: +? Bastien Remy: ?? Matiss: +? Thierry D.: +? Ihor Vorotnov: ?? Hugo Alliaume: ?? Juan Millan: +? Olbaum: +? Steve Baumann: ?? James Mallison: ?? Marco Deleu: ?? TheGenuinenessSheriff: ++ Golgote: ?? ++: 13 definitely prefer changing to something other than @@ (though not necessarily #[]) +?: 10 probably prefer changing to something other than @@ (though not necessarily #[]) ??: 23 hard-to-tell/weak/uncertain/they-all-suck -?: 3 probably prefer to keep @@ --: 4 definitely prefer to keep @@ So, the majority of Twitter respondents in that thread appear to be against @@, and in favor of "something else" (24 to 7). Having pointed all that out, I note that Twitter is not the voting mechanism here. Further, I opine that "voting repeatedly until the voters get it 'right' and then calling the matter settled for all time" is not how decision-by-voting is supposed to work. Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote? -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  111228
July 28, 2020 19:07 ben@benramsey.com (Ben Ramsey)
> On Jul 28, 2020, at 13:55, Paul M. Jones <pmjones@pmjones.io> wrote: > > Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote?
IMO, there is no compelling reason to revote other than the fact that we have no process for what to do in this situation. However, given that we used ranked-choice voting in the last RFC, the logical choice (to me) seems to be: choose the runner-up in the event that the winner is disqualified. So, if there are extenuating circumstances that result in `@@` being disqualified, we should automatically default to the runner-up in the ranked-choice outcome. Cheers, Ben
  111229
July 28, 2020 19:10 pmjones@pmjones.io ("Paul M. Jones")
> On Jul 28, 2020, at 14:07, Ben Ramsey <ben@benramsey.com> wrote: > >> On Jul 28, 2020, at 13:55, Paul M. Jones <pmjones@pmjones.io> wrote: >> >> Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote? > > > IMO, there is no compelling reason to revote other than the fact that we have no process for what to do in this situation.
What "situation" is this, exactly? AFICT we have a working implementation using @@, with no technical hurdles to surmount. Or have I missed something that now prevents @@ from working per its RFC? -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  111230
July 28, 2020 19:15 ben@benramsey.com (Ben Ramsey)
> On Jul 28, 2020, at 14:10, Paul M. Jones <pmjones@pmjones.io> wrote: > >> On Jul 28, 2020, at 14:07, Ben Ramsey <ben@benramsey.com> wrote: >> >>> On Jul 28, 2020, at 13:55, Paul M. Jones <pmjones@pmjones.io> wrote: >>> >>> Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote? >> >> >> IMO, there is no compelling reason to revote other than the fact that we have no process for what to do in this situation. > > What "situation" is this, exactly? AFICT we have a working implementation using @@, with no technical hurdles to surmount. Or have I missed something that now prevents @@ from working per its RFC?
The new RFC outlines reasons why `@@` is a sub-optimal choice. TL;DR: * current parser conflict (which can be worked around) * possibility for further (as of yet unknown) parsing issues * a closing ] makes it easier to extend Attributes with more syntax, and at the same time not be at the risk of running into parser conflicts * userland analysis tools have difficulties parsing `@@` Cheers, Ben
  111232
July 28, 2020 19:39 pmjones@pmjones.io ("Paul M. Jones")
> On Jul 28, 2020, at 14:15, Ben Ramsey <ben@benramsey.com> wrote: > >> On Jul 28, 2020, at 14:10, Paul M. Jones <pmjones@pmjones.io> wrote: >> >>> On Jul 28, 2020, at 14:07, Ben Ramsey <ben@benramsey.com> wrote: >>> >>>> On Jul 28, 2020, at 13:55, Paul M. Jones <pmjones@pmjones.io> wrote: >>>> >>>> Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote? >>> >>> >>> IMO, there is no compelling reason to revote other than the fact that we have no process for what to do in this situation. >> >> What "situation" is this, exactly? AFICT we have a working implementation using @@, with no technical hurdles to surmount. Or have I missed something that now prevents @@ from working per its RFC? > > > The new RFC outlines reasons why `@@` is a sub-optimal choice.
And yet it was the one chosen by the voting process. (Silly voters, making sub-optimal choices!) The rest of your message reveals what I thought was true: i.e., there are no currently-verified technical barriers to @@. To wit:
> * current parser conflict (which can be worked around)
AFAICT that pre-existing problem has been fixed, so this is a non-issue.
> * possibility for further (as of yet unknown) parsing issues
IOW, imaginary issues, aka FUD.
> * a closing ] makes it easier to extend Attributes with more syntax, and at the same time not be at the risk of running into parser conflicts
Maybe, maybe not. This has the strongest possibility of becoming a technical argument, but no competing implementation (with a comparative implementation using @@) has been presented as an example. So as it stands now, this also is imaginary.
> * userland analysis tools have difficulties parsing `@@`
Though it does not seem insurmountable for those userland authors. Also, this is an interesting take: does Internals now defer to userland? If so, maybe it's time to open up voting more widely, so that the whole of userland can be represented more effectively here. Again, I don't especially care if @@, <<>>, or #[], or something else makes it through. Annotations of some sort seem like a nice idea, and I think they'd be of benefit. But if we are to make decisions by what is ostensibly a democratic process, we should stick to the voted decisions, instead of re-voting issues until the voters "get it right" according to some implicit and unstated criteria. (If re-voting over and over is the plan, I've got some RFCs I might like to revisit as well.) -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  111243
July 29, 2020 06:13 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)
Hi Paul,

wt., 28 lip 2020 o 20:56 Paul M. Jones <pmjones@pmjones.io> napisał(a):

> ... > Let's count. + is "change away from @@ to anything else", - is "stay with > @@", ? is hard-to-tell/weak/uncertain/they-all-suck. > ... > Michal Brzuchalski: -? >
Wow. Hold on your horses. I was never in favour for @@ but always against at least AFAIR. Where did you get that? Anyway it should be ++ here
> > ++: 13 definitely prefer changing to something other than @@ (though not > necessarily #[]) >
++: 14 definitely prefer changing to something other than @@ (though not necessarily #[])
> +?: 10 probably prefer changing to something other than @@ (though not > necessarily #[]) > ??: 23 hard-to-tell/weak/uncertain/they-all-suck > -?: 3 probably prefer to keep @@ >
-?: 2 probably prefer to keep @@ --: 4 definitely prefer to keep @@
>
It's hard to rely fully on your statement considering such a mistake. Cheers, Michał Marcin Brzuchalski
  111247
July 29, 2020 12:41 pmjones@pmjones.io ("Paul M. Jones")
Hi Michal,

> On Jul 29, 2020, at 01:13, Michał Marcin Brzuchalski brzuchalski@gmail.com> wrote: > > Hi Paul, > > wt., 28 lip 2020 o 20:56 Paul M. Jones <pmjones@pmjones.io> napisał(a): > >> ... >> Let's count. + is "change away from @@ to anything else", - is "stay with >> @@", ? is hard-to-tell/weak/uncertain/they-all-suck. >> ... >> Michal Brzuchalski: -? >> > > Wow. Hold on your horses. I was never in favour for @@ but always against > at least AFAIR. > Where did you get that? > > Anyway it should be ++ here
Ah yes, clearly a mistake -- my apologies.
> It's hard to rely fully on your statement considering such a mistake.
I encourage you (and everyone sle who is interested!) to go back and check that Twitter thread to see if I have made other errors. In the absence of them, my conclusion still stands: that is, "the majority of Twitter respondents in that thread appear to be against @@, and in favor of 'something else'." -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  111231
July 28, 2020 19:38 marandall@php.net (Mark Randall)
On 28/07/2020 18:57, Theodore Brown wrote:
>> 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.
Just because they haven't, does not mean we won't. Unless there's a good reason to do otherwise, we should provide for future flexibility where possible. I previously provided examples of ways in which we might want to extend the syntax. Most things in PHP allow some level of scope restriction, such as private or protected. One day we may want to extend annotations to include such a feature, such as a protected annotation that can only be accessed by the class itself or its descendants. #[protected MyAttribute(xyz)] Attributes are not validated when they are encountered, this may be something that we wish to allow attributes to opt-in to in future. #[checked MyAttribute(xyz]) In future we might want to offer APIs that return an array of all of the instances (moving the creation up from newInstance) and then tighten up the behvaiour for classes which do not exist (because they might belong to an optional package, such as debugging or code analysis). This might come in the form of something like: #[optional MyAttribute(xyz)] Some of these might happen, none of these might happen, something completely different might happen. What is clear is we've got to support Attributes for 20, 30 years, and we should leave the door open for easier and cleaner syntax additions if there's no compelling reason not to. -- Mark Randall
  111233
July 28, 2020 19:52 joe@joeferguson.me (Joe Ferguson)
On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown <theodorejb@outlook.com>
wrote:

> > 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: >
Theodore, thanks for your comments, time, and work on the Shorter Attribute Syntax RFC. I appreciate your feedback and I'm also of the mind where I don't care based on looks alone. The RFC also notes the @@ issues have been resolved by the RFC closing at the end of the month. My motivation for this RFC is based on 2 things: Firstly, the @@ syntax makes parsing harder (although not impossible) on CLI tools such as PHPCS. Therefore IMHO internals should make the best effort to avoid this when possible. Secondly, I'd like to see internals use this as a point in the future to avoid this kind of issue where we need to vote on something yet again instead of taking the runner up in a ranked-choice vote. Originally this was my main motivation until I saw the issues raised by the PHPCS users. I don't want this to become an issue of "keep voting until we get the vote we like" as Paul mentioned. This RFC is my attempt to set a precedent where internals allows itself to be some measurement more autonomous than it currently is today. And also to try to make the 8.0 upgrade process a bit friendlier to our fiends writing userland code. https://wiki.php.net/rfc/shorter_attribute_syntax -- - Joe Ferguson JoeFerguson.me osmihelp.org
  111234
July 28, 2020 19:58 marcio.web2@gmail.com (Marcio Almada)
Hi,

> > On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown <theodorejb@outlook.com> > wrote: > > > > > 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: > > > > > > Theodore, thanks for your comments, time, and work on the Shorter Attribute > Syntax RFC. I appreciate your feedback and I'm also of the mind where I > don't care based on looks alone. The RFC also notes the @@ issues have been > resolved by the RFC closing at the end of the month. > > My motivation for this RFC is based on 2 things: > > Firstly, the @@ syntax makes parsing harder (although not impossible) on > CLI tools such as PHPCS. Therefore IMHO internals should make the best > effort to avoid this when possible. > > Secondly, I'd like to see internals use this as a point in the future to > avoid this kind of issue where we need to vote on something yet again > instead of taking the runner up in a ranked-choice vote. Originally this > was my main motivation until I saw the issues raised by the PHPCS users. >
Is this issue documented somewhere on github or on any other platform? I'd like to see the discussion and maybe participate in it. Thanks, Márcio
  111235
July 28, 2020 20:46 petercowburn@gmail.com (Peter Cowburn)
(Top posting because... sue me.)

I hereby propose to use @[] syntax for attributes.

No need to vote; it's clearly the best, nay only, real option.

Make it so.

P.S. Sorry for suggesting @@ earlier, I've no idea what I was thinking.
Creating new syntax is HARD!
P.P.S. <3

On Tue, 28 Jul 2020 at 20:59, Marcio Almada web2@gmail.com> wrote:

> Hi, > > > > > On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown <theodorejb@outlook.com> > > wrote: > > > > > > > > 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: > > > > > > > > > > > Theodore, thanks for your comments, time, and work on the Shorter > Attribute > > Syntax RFC. I appreciate your feedback and I'm also of the mind where I > > don't care based on looks alone. The RFC also notes the @@ issues have > been > > resolved by the RFC closing at the end of the month. > > > > My motivation for this RFC is based on 2 things: > > > > Firstly, the @@ syntax makes parsing harder (although not impossible) on > > CLI tools such as PHPCS. Therefore IMHO internals should make the best > > effort to avoid this when possible. > > > > Secondly, I'd like to see internals use this as a point in the future to > > avoid this kind of issue where we need to vote on something yet again > > instead of taking the runner up in a ranked-choice vote. Originally this > > was my main motivation until I saw the issues raised by the PHPCS users.. > > > > Is this issue documented somewhere on github or on any other platform? > I'd like to see the discussion and maybe participate in it. > > Thanks, > Márcio > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  111307
August 4, 2020 07:31 come.chilliet@fusiondirectory.org (=?UTF-8?B?Q8O0bWU=?= Chilliet)
Le Tue, 28 Jul 2020 17:57:34 +0000,
Theodore Brown <theodorejb@outlook.com> a écrit :

> 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.
For those which like me do not know Rust, I checked and it appears that "#" is only used for attributes in Rust, and is not a comment starter. So that explains why it makes sense for Rust to use this. But it still feels like a really bad idea to me to mix comment and code in PHP.
  111239
July 29, 2020 00:21 tysonandre775@hotmail.com (tyson andre)
Hi internals,

For #[, my main objection is the various ways this can change the lexing in a way that is impractical to (efficiently) backfill,
and that the proposed patch doesn't address the fact that the syntax may change the syntax of php 7 code in unexpected ways. 

This syntax would help phpcs with easy examples **in the short term**, when attributes are on a single line,
but would make more complicated refactorings buggy and error-prone unless phpcbf was run in the same major version.
When attributes span multiple lines, the lexing is completely different for `#[]`.
For example, the below syntax would yield false in php 7, but a generator in php 8.
(There's precedent at least - the lexing of heredocs changed in php 7.3 or 7.4)

```
// Aside: This code snippet seems to have an assert failure in the lexer with the patch in the RFC
// Zend/zend_compile.c:1794: zendlex: Assertion `!(executor_globals.exception) || ret == T_ERROR' failed.
function generator() {
    yield #[MyCustomAttribute('
        false;
        // ']function() {};
}
```

And another example which would cause problems for phpcs in php 7 - the comment syntax can cause code to be treated as inline html instead of php tokens.

```
https://some-website/reason?>')]
function main() {}
const APP_SECRET = 'app-secret';
echo "Test\n";
```

I'd posted another example in https://externals.io/message/111101#111133

One way I'd thought of to avoid this ambiguity would be to assert in PHP 8.0 with an E_COMPILE_ERROR (or E_COMPILE_WARNING) that:
1. All tokens of the #[...] annotation are on the same line
2. No non-whitespace token follows the ] on the same line.
    It may be permissible to allow other `//` comments or multiple attributes after it on the same line, though.
3. No `?>` substrings within the rest of the line after #[, maybe

Although I'm not sure if others are actually concerned about this ambiguity and these are really artificial examples for code.

As for `<<`, I'm assuming people may have meant `yield <> function() {};`,
but `yield` already has a precedence and didn't have issues - otherwise `yield+2;`  could be adding 2 to the result of a yield.
(It's unambiguously `yield(+2);` right now).
I forget how it'd be parsed, but it wouldn't be ambiguous.

As for `@@`, all of its known issues seem to have been resolved,
and there is still the potential for future issues, but I still prefer it over the `#[` implementation in that patch.

P.S. I'd like to note that
1. A lot more discussion has occurred since the initial vote.
2. Since `@@` was obviously passing at the time, fewer voters would put much thought into detailed tradeoffs of `#[`
3. I haven't seen those specific drawbacks to `#[` of potentially significantly changing lexing (not just losing tokens) mentioned,
   but the shorter attributes syntax RFC did seem to mention params were commented out.

One idea I'd have on voting would be to have the exact same 3-way vote, again, and pick the attribute syntax with the same ranked choice procedure.
I assume proponents of `#[` would have similar objections if an RFC with a two-way vote for  `<<>>` and `@@` was started first.

Regards,
- Tyson
  111244
July 29, 2020 07:23 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Jul 29, 2020 at 2:21 AM tyson andre <tysonandre775@hotmail.com>
wrote:

> Hi internals, > > For #[, my main objection is the various ways this can change the lexing > in a way that is impractical to (efficiently) backfill, > and that the proposed patch doesn't address the fact that the syntax may > change the syntax of php 7 code in unexpected ways. > > This syntax would help phpcs with easy examples **in the short term**, > when attributes are on a single line, > but would make more complicated refactorings buggy and error-prone unless > phpcbf was run in the same major version. > When attributes span multiple lines, the lexing is completely different > for `#[]`. > For example, the below syntax would yield false in php 7, but a generator > in php 8. > (There's precedent at least - the lexing of heredocs changed in php 7.3 or > 7.4) >
That's an interesting point. Emulating #[] lexing on older versions will definitely be a challenge for PHP-Parser. I don't think we should make concerns of external tooling hold us back too much, but the phpcs argument really doesn't hold water. Regards, Nikita
> ``` > // Aside: This code snippet seems to have an assert failure in the lexer > with the patch in the RFC > // Zend/zend_compile.c:1794: zendlex: Assertion > `!(executor_globals.exception) || ret == T_ERROR' failed. > function generator() { > yield #[MyCustomAttribute(' > false; > // ']function() {}; > } > ``` > > And another example which would cause problems for phpcs in php 7 - the > comment syntax can cause code to be treated as inline html instead of php > tokens. > > ``` > // This example echoes the rest of the source code in php 7 > // and echoes "Test" in php 8. > #[DeprecationReason('reason: <https://some-website/reason?>')] > function main() {} > const APP_SECRET = 'app-secret'; > echo "Test\n"; > ``` > > I'd posted another example in https://externals.io/message/111101#111133 > > One way I'd thought of to avoid this ambiguity would be to assert in PHP > 8.0 with an E_COMPILE_ERROR (or E_COMPILE_WARNING) that: > 1. All tokens of the #[...] annotation are on the same line > 2. No non-whitespace token follows the ] on the same line. > It may be permissible to allow other `//` comments or multiple > attributes after it on the same line, though. > 3. No `?>` substrings within the rest of the line after #[, maybe > > Although I'm not sure if others are actually concerned about this > ambiguity and these are really artificial examples for code. > > As for `<<`, I'm assuming people may have meant `yield <> function() > {};`, > but `yield` already has a precedence and didn't have issues - otherwise > `yield+2;` could be adding 2 to the result of a yield. > (It's unambiguously `yield(+2);` right now). > I forget how it'd be parsed, but it wouldn't be ambiguous. > > As for `@@`, all of its known issues seem to have been resolved, > and there is still the potential for future issues, but I still prefer it > over the `#[` implementation in that patch. > > P.S. I'd like to note that > 1. A lot more discussion has occurred since the initial vote. > 2. Since `@@` was obviously passing at the time, fewer voters would put > much thought into detailed tradeoffs of `#[` > 3. I haven't seen those specific drawbacks to `#[` of potentially > significantly changing lexing (not just losing tokens) mentioned, > but the shorter attributes syntax RFC did seem to mention params were > commented out. > > One idea I'd have on voting would be to have the exact same 3-way vote, > again, and pick the attribute syntax with the same ranked choice procedure. > I assume proponents of `#[` would have similar objections if an RFC with a > two-way vote for `<<>>` and `@@` was started first. > > Regards, > - Tyson > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  111240
July 29, 2020 01:11 kontakt@beberlei.de (Benjamin Eberlei)
Hi Joe,

Personally I favor #[] myself, but there has been a vote with a substantial
participation choosing @@. Overturning this democratic outcome should
require **significant** technical arguments, otherwise this RFC would
provide problematic precedent for any RFC to be overturned by arbitrary
revoting.

The arguments the RFC brings forward don't convince me that we should pick
#[] over @@.

1. The parser conflict was my major reason why @@ should not have been
picked from a technical POV. But this issue has been fixed by an
independent improvement since then. These kinds of small problems are found
regularly after RFCs are accepted and are subsequently fixed. The RFC is
formulated as the problem still exists, but it does not. Yes, the namespace
token RFC vote has not yet finished, but there is no chance it will be
rejected at this point.

Since the namespace token RFC is passing, and I have seen the simplicity of
the new parser rules, my opinion has changed to keep pushing for #[] and I
accept the @@ outcome.

2. The phpcs argument also does not convince me.

Summed up it is essentially that a current version of phpcs does not
support parsing @@ or <<>> yet and incorrectly changes code using them,
however for #[] it does nothing because it parses it as a comment. To me
this sounds like a bug in PHPCS. This argument also breaks down completely
on multi line attributes.

Why should we even expect PHPCS to support an unreleased version? If
someone uses PHP 8 code, why do we assume they keep using an old version of
phpcs that does not support PHP 8 yet?

3. We already established that the syntax question is extremely
contentious, and I was getting tons of messages on it on Twitter, Reddit,
Email et al during the initial Attributes RFC. So of course people would be
against @@ (as I am myself), however it had a majority in votes.

For me putting these subjective opinions into the RFC makes the case for
overturning less convincing, because it makes the argument that overturning
a valid democratic vote is somehow OK if you are loud.

The only reason why we change this outcome must be purely technical imho.

4. You cannot write a regex to detect the end symbols for both #[] or <<>>,
because both end symbols are allowed *inside* the attribute syntax already,
so it's not easier to find occurrences with regexes with the other syntaxes:

#[Foo([1 => 2])]
<> 4)>>

Simple detection of attributes will always need to grep only for the start
token, and both @@ and #[ are equally unique to find here.

5. For readability an end token would be nicer (which is why i prefer #[]).
But this information was already known during the first vote on the syntax
and rejected by majority.

6. An end token might indeed allow extending attributes with new stuff, but
nobody has brought up this use-case before. No other language has
additional attribute keywords, why is this brought as a positive argument,
when the choice of syntax no other language uses is brought up as a
negative point later?

7. Future potential parsing problems are brought forward for @@, but #
being a comment token makes it likely that #[] will also cause problems.
Tyson has a few examples in his email to this thread.

Other confusing things you can do with #[] for example:

#[Foo( 1 # 1 ] bar
)]
function foo () { }

Which is #[Foo(1)] without comments and line breaks.
  111280
August 2, 2020 15:06 derick@php.net (Derick Rethans)
On Wed, 29 Jul 2020, Benjamin Eberlei wrote:

> Personally I favor #[] myself, but there has been a vote with a > substantial participation choosing @@. Overturning this democratic > outcome should require **significant** technical arguments, otherwise > this RFC would provide problematic precedent for any RFC to be > overturned by arbitrary revoting. > > The arguments the RFC brings forward don't convince me that we should > pick #[] over @@.
However, one other thing just came to light where the "Shorter Syntax" RFC was unclear about: no longer supporting grouping. Changing the accepted << .. >> syntax breaks something that was accepted through "Attribute Amendments": grouping, as per https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes The switch to @@ does now not allow for this, but we haven't spefically voted on we wanted to get rid of grouping. The Shorter Syntax RFC does talk about it in "Verbosity" (https://wiki.php.net/rfc/shorter_attribute_syntax#verbosity), but that's not a technical reason, just opinion about readability. 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
  111282
August 2, 2020 16:02 theodorejb@outlook.com (Theodore Brown)
On Sun, Aug 2, 2020 at 10:06 AM Derick Rethans <derick@php.net> wrote:

> On Wed, 29 Jul 2020, Benjamin Eberlei wrote: > > > Personally I favor #[] myself, but there has been a vote with a > > substantial participation choosing @@. Overturning this democratic > > outcome should require **significant** technical arguments, otherwise > > this RFC would provide problematic precedent for any RFC to be > > overturned by arbitrary revoting. > > > > The arguments the RFC brings forward don't convince me that we should > > pick #[] over @@. > > However, one other thing just came to light where the "Shorter Syntax" > RFC was unclear about: no longer supporting grouping. > > Changing the accepted << .. >> syntax breaks something that > was accepted through "Attribute Amendments": grouping, as per > https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes > > The switch to @@ does now not allow for this, but we haven't spefically > voted on we wanted to get rid of grouping. The Shorter Syntax RFC does > talk about it in "Verbosity" > (https://wiki.php.net/rfc/shorter_attribute_syntax#verbosity), but > that's not a technical reason, just opinion about readability.
Hi Dereck, The Shorter Attribute Syntax RFC explicitly mentioned that the @@ syntax would supersede the grouped attributes proposal: [1]
> this proposal does not conflict with the Attribute Amendments RFC, > with the exception that if the @@ syntax is accepted, it will > supersede the syntax for grouped attributes.
This was also documented in the Attribute Amendments RFC itself: [2]
> This feature would be superseded by any other RFC getting accepted > that changes the syntax.
I agree with Benjamin that the democratic outcome of the vote between <<>>, @@, and #[] should not be overturned unless there is a serious technical problem with the implementation, otherwise we set precedent for someone to overturn any RFC by arbitrarily re-voting until they get the result they want. Best regards, Theodore [1]: https://wiki.php.net/rfc/shorter_attribute_syntax#unaffected_functionality [2]: https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes
  111287
August 2, 2020 21:40 Danack@basereality.com (Dan Ackroyd)
Theodore Brown  wrote:
> > The Shorter Attribute Syntax RFC explicitly mentioned that the @@ > syntax would supersede the grouped attributes proposal: [1]
From the RFC:
> > # Unaffected Functionality > ...it will supersede the syntax for grouped attributes.
I missed that change at least in part because it's listed under "unaffected functionality". Even reading it now, it's not obvious that "superseded" means "grouped attributes won't be supported". cheers Dan Ack
  111289
August 3, 2020 00:09 theodorejb@outlook.com (Theodore Brown)
On Sun, Aug 2, 2020 at 4:40 PM Dan Ackroyd <Danack@basereality.com> wrote:

> Theodore Brown wrote: > > > > The Shorter Attribute Syntax RFC explicitly mentioned that the @@ > > syntax would supersede the grouped attributes proposal: [1] > > From the RFC: > > > > # Unaffected Functionality > > ...it will supersede the syntax for grouped attributes. > > I missed that change at least in part because it's listed under > "unaffected functionality". > > Even reading it now, it's not obvious that "superseded" means "grouped > attributes won't be supported".
Hi Dan, I'm not sure it can really be called a change, since at the time the Shorter Attribute Syntax RFC went to vote the Attribute Amendments RFC had not yet been accepted (and it certainly wasn't clear whether the grouped attribute proposal would pass). Anyway, the whole point of the grouped attribute syntax was to alleviate some of the verbosity of the << and >> tokens when adding multiple attributes. The @@ syntax supersedes, or replaces grouped attributes since in real-world use cases it is even less verbose than the grouped attribute proposal, [1] while avoiding its additional implementation complexity. Kind regards, Theodore [1]: https://externals.io/message/110355#110414
  111246
July 29, 2020 10:44 someniatko@gmail.com (someniatko)
Hello Internals,

Here is a small comparison table based on current feedback, maybe it
will bring some objective clarity to the discussion:
(markdown below)

Impact|`@@`|`#[]`
---|---|---
BC break|virtualy nonexistent|slightly broader: `##[` comments are now broken.
Parser|no technical problems by now|no technical problems by now
Extendability|less future-proof, arguably|more future-proof, arguably
Grepability|harder, arguably|easier, arguably (however, consider an
Attribute taking an array `[]` parameter.)
Perception|similar to PHPDoc annotations, more familiar to PHP
devs|more familiar to Rust devs

Other issues are either speculative or insignificant (as for me):
- causing future parsing issues: no evidence
- "backfilling": there is, arguably, no use case for it. Code using
PHP 8 features will target PHP 8 anyway. Code, compatible with both
PHP 7 and PHP 8 would most probably use classic PHPDoc annotations.
- "syntax no other language uses": this is probably insignificant.
- "possibility of @@ moving to @ is near to 0": i am not sure anyone
planned to move @@ to @, and if so, it would be an unnecessary BC
break.

I am personally in favor of `@@`, but just because it looks visually
nicer to me. I see no strong objective reason to favor one over the
other. If you want an ending token, maybe consider `@@Attribute@@`,
personally I like those round-ish shapes :P.

On Tue, Jul 28, 2020 at 5:47 PM 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. > > -- > - Joe Ferguson > JoeFerguson.me > osmihelp.org
  111248
July 29, 2020 16:29 tysonandre775@hotmail.com (tyson andre)
Hi internals,

I had thought of another alternative syntax - `/** @@MyAttribute */`, which would solve some of the problems I mentioned about `#[`.

```
namespace My\NS;
use Other\MyAttribute;
/**
 * Use @@ or << at the start of a line. (To be determined)
 * Resolve the names in the comment relative to the scope of the function, like the current attribute implementation.
 * @@MyAttribute(expr, expr)
 * Extra *s are allowed
 *** @@AnotherAttribute
 * Tokenizing should continue until a matching ) is found
 * @@YetAnotherAttribute(
 *   expr
 *)
 */
function my_function() {
}
```

Pros:
- Doc comments are already the recommended way to associate information with a named element.
- Most code modifying tools will preserve doc comments
- This can go on the same line as a closure/short arrow function without lexing ambiguity.
- Frameworks can use `Reflection*->getDocComment()` and update their checks to also allow `@@` for attribute-like annotations when run in PHP 7.
   They don't have to repeat both `@@MyAttribute` and `/** @MyAttribute */` or risk it going out of sync
   (Symfony would already have to parse the `use` clauses to find out what `@MyAttribute` resolves to for Symfony attributes)
- Does not affect lexing outside of the doc comment
- I don't believe @@ is common. To minimize the impact on ascii art, this can be initially limited to @@ at the start of a comment line (spaces and `*`s) immediately followed by \ or the start of an identifier

Cons:
- Need to run the lexer twice on a T_DOC_COMMENT token, but only if the comment string contains `@@` and is associated with an element.
   Emitting T_DOC_COMMENT_START and T_DOC_COMMENT_END and T_DOC_COMMENT_INNER and T_DOC_COMMENT_ATTRIBUTE
   T_DOC_COMMENT_ATTRIBUTE_ERROR might make this technically feasible (similar to heredoc having complicated logic)
- I prefer `@@` and `<<>>` over this proposal long-term, after php 7.4 support is dropped.
  But I prefer `/** @@MyAttr */` over `#[MyAttr]`.
- Would end up emitting parse errors for some existing code in the second lexer pass.
- Syntax highlighting might be hard to implement in editors, but probably tractable.

I don't remember seeing this proposed before. I believe @@ isn't used by mainstream frameworks in doc comments right now, but correct me if it is.

Thanks,
- Tyson
  111253
July 29, 2020 18:40 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)
Hi Joe,

wt., 28 lip 2020 o 16:47 Joe Ferguson <joe@joeferguson.me> napisał(a):

> 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. >
Thank you for bringing this up. TIL something new about popular framework templating component which I wanna share with you. There is already use of @@ in files with ".php" extension in Blade templates from Laravel framework. In Laravel 7.x double @@ is used as an escape sequence allowing template compiler to passthrough TypeScript expressions with @decorator() which is described in the Templating section of manual[1]. I realize that it's not the same cause the double @@ is used here inside ".php" files in HTML mode and not in PHP code mode but since this feature exist it may cause issues on a text search lookup using for eg. grep | sed | awk like tools. TL;DR Now please bear in mind that I'm just saying that people from Larevil community already can use the same syntax with double "@@name()" in ".php" files but outside of PHP code context. [1] https://laravel.com/docs/7.x/blade#blade-and-javascript-frameworks Cheers, Michał Marcin Brzuchalski
  111261
July 30, 2020 12:50 kontakt@beberlei.de (Benjamin Eberlei)
I think it has become clear that we need to revisit this syntax question
again, including the elephpant in the room of delaying this feature to 8.1.

The reason is not only Joe's desire to revote on #[], but also that there
are now more syntax proposals such as @[] by Derick or @@ in comments by
Tyson (though no patch exists for it yet). At this point a lot of syntaxes
are potentially viable (except single @, please don't suggest it).

I feel the choice between many syntaxes is 80% subjective, 20% objective
facts, so tensions are to be expected.

As the author of the original RFC and patch, I hope I have some klout in
suggesting the following procedure (RMs would need to extend their approval
for revote to this).

1. we collect syntax proposals once again, with the requirement of a simple
patch being available against php-src/master for viability in 8.0.

2. RMs are the arbiter to decide the patch is acceptable to be included for
8.0 or if its selection would delay entire attributes to 8.1.

3. I would make a feature matrix for the vote / RFC page and sort each
proposed syntax into it, seeking input from the proposers.

4. We would then hold another vote on syntax using STV where the choice is
a combination of syntax and target version, examples:

- <<>> in 8.0, #[] in 8.0, @@ in 8.0 (all these patches are viable)
- @@ in doc blocks for 8.1
- §[] in 8.1 (weird example to demonstrate the point)

and so on. The STV vote would run with potentially 5-10 different syntaxes.

On Time Frame: Sara allowed to extend this decision into feature freeze,
but I believe it shouldn't be later than Beta 2 (August 20th), especially
if the outcome could be delay until 8.1.

What do RMs think of voting from 10th to 17th of August, giving us 3 days
to merge. This gives everyone until August 8-9th to work on their syntax
proposal.

greetings
Benjamin

On Tue, Jul 28, 2020 at 4:47 PM 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. > > -- > - Joe Ferguson > JoeFerguson.me > osmihelp.org >
  111263
July 30, 2020 13:27 joe@joeferguson.me (Joe Ferguson)
On Thu, Jul 30, 2020 at 7:50 AM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

> I think it has become clear that we need to revisit this syntax question > again, including the elephpant in the room of delaying this feature to 8.1. > > The reason is not only Joe's desire to revote on #[], > > No, I *do not* want to revote. This RFC simply takes a formal approach to
approve the syntax that came in 2nd based on concerns raised with the @@ syntax. Now that it seems the technical concerns around @@ have been resolved by another pending, passing, RFC, I'm still here wanting us to talk about the impact of @@ on static analysis tools. Apparently, internals doesn't care about these projects. I care and I'm trying to help. I'm not trying to revote until I get the vote I want. I'm just a dude that had some free time while on vacation when he saw a chance to contribute. I see two possible outcomes: Release Managers collectively should decide what we do to move forward. Either accept @@, we'll decline this RFC and we can move on to the next nearest bikeshed. OR If Release Managers don't want to, or can't collectively make a decision then this RFC should go to a vote and we'll see what 2/3s of the group want. I'm fine with either outcome. https://wiki.php.net/rfc/shorter_attribute_syntax_change -- - Joe Ferguson JoeFerguson.me osmihelp.org
  111264
July 30, 2020 13:31 david.proweb@gmail.com (David Rodrigues)
I would like to suggests the syntax "using attribute(Attribute, ...)". It
is more clear and should not create BC.

Em qui, 30 de jul de 2020 10:28, Joe Ferguson <joe@joeferguson.me> escreveu:

> On Thu, Jul 30, 2020 at 7:50 AM Benjamin Eberlei <kontakt@beberlei.de> > wrote: > > > I think it has become clear that we need to revisit this syntax question > > again, including the elephpant in the room of delaying this feature to > 8.1. > > > > The reason is not only Joe's desire to revote on #[], > > > > > No, I *do not* want to revote. This RFC simply takes a formal approach to > approve the syntax that came in 2nd based on concerns raised with the @@ > syntax. > > Now that it seems the technical concerns around @@ have been resolved by > another pending, passing, RFC, I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. I care and I'm trying to help. I'm not trying to > revote until I get the vote I want. I'm just a dude that had some free time > while on vacation when he saw a chance to contribute. > > I see two possible outcomes: > > Release Managers collectively should decide what we do to move forward. > Either accept @@, we'll decline this RFC and we can move on to the next > nearest bikeshed. > > OR > > If Release Managers don't want to, or can't collectively make a decision > then this RFC should go to a vote and we'll see what 2/3s of the group > want. > > I'm fine with either outcome. > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > -- > - Joe Ferguson > JoeFerguson.me > osmihelp.org >
  111266
July 30, 2020 14:09 tysonandre775@hotmail.com (tyson andre)
Hi David,

> I would like to suggests the syntax "using attribute(Attribute, ...)". It > is more clear and should not create BC.
I'd agree that it's implementable and works with the tokenizer. My main objection is the verbosity, which is the reason I assume many other languages have fairly short/distinct attribute syntax. ``` // Assume Unused tells IDEs/analyzers/linters not to warn about unused parameters, // and Override warns about a method not being an override using attribute(Override) public function apiMethod( using attribute(Unused) array $params, using attribute(Unused) bool $featureEnabled, using attribute(Unused) array $options, ) {...} ``` - Tyson
  111267
July 30, 2020 14:33 david.proweb@gmail.com (David Rodrigues)
I think that verbosity is not a problem if compared to "strange mixed
symbols", mainly to new users. Google it is a bit hard "what means double
at". And "using attribute" is very clear.

Anyway, I think that is valid we use it for now until we have a good symbol
arrangement, and on future we could have the "verbose syntax" ("using
attribute()") and shortened syntax (to be decided, but like "#[...]").

Atenciosamente,
David Rodrigues


Em qui., 30 de jul. de 2020 às 11:09, tyson andre <tysonandre775@hotmail.com>
escreveu:

> Hi David, > > > I would like to suggests the syntax "using attribute(Attribute, ...)". It > > is more clear and should not create BC. > > I'd agree that it's implementable and works with the tokenizer. > > My main objection is the verbosity, which is the reason I assume many > other languages have fairly short/distinct attribute syntax. > > ``` > // Assume Unused tells IDEs/analyzers/linters not to warn about unused > parameters, > // and Override warns about a method not being an override > > using attribute(Override) > public function apiMethod( > using attribute(Unused) > array $params, > using attribute(Unused) > bool $featureEnabled, > using attribute(Unused) > array $options, > ) {...} > ``` > > - Tyson
  111268
July 30, 2020 15:57 rowan.collins@gmail.com (Rowan Tommins)
On Thu, 30 Jul 2020 at 14:28, Joe Ferguson <joe@joeferguson.me> wrote:

> ... I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. >
I don't think that's a reasonable summary of this thread at all. I've seen three main types of response: 1) "I haven't followed the discussion about PHPCS, please could you summarise the problem." 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x syntax." 3) "I think #[] will cause as many problems for such tools as @@, just in different places." Maybe they weren't always as polite or succinct as that, but not agreeing with you is not the same as not caring. As far as I can make out, attributes that appear entirely on a single line with no other text are trivial to ignore in any parser whatever the syntax. That trivial case is slightly more trivial with #[] because a PHP 7 parser will treat it as a line comment; but add a rule to your parser to also treat "@@" as a line comment, and you're done. The problems come when you have a) an attribute definition spanning multiple lines, and/or b) an attribute definition inline with other code. As soon as you have that, you have no choice but to parse the code entirely according to the grammar of PHP 8, not as "PHP 7 with some warts". If detecting the end of annotation tokens is really that difficult, would it suffice to make the () mandatory (i.e. @@Deprecated() rather than @@Deprecated)? The rules for what could appear between @@ and ( are pretty simple, and finding the correct ending ) should be pretty much the same effort as finding the correct ending ], since both can occur in matching pairs inside the argument list. Regards, -- Rowan Tommins [IMSoP]
  111269
July 30, 2020 16:18 guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")
Question: The key factor of not using @ is due to conflict of
suppression symbol.
While we are in a major (where BC breaks are not encourage, but
tolerable), have we considered the possibility of BC breaking
suppression symbol (@ would become @@) and using @ for Attributes?

I bet a search/replace wouldn't be that hard to be achieved, and it
would function even today (as @@ is acceptable). Basically, it's a BC
break where code needs to be changed, but backwards compatible as new
suppressor symbol is backwards compatible with previous versions of
PHP.

Just some food for thought....

On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins collins@gmail.com> wrote:
> > On Thu, 30 Jul 2020 at 14:28, Joe Ferguson <joe@joeferguson.me> wrote: > > > ... I'm still here wanting us to talk about the > > impact of @@ on static analysis tools. Apparently, internals doesn't care > > about these projects. > > > > > I don't think that's a reasonable summary of this thread at all. I've seen > three main types of response: > > 1) "I haven't followed the discussion about PHPCS, please could you > summarise the problem." > 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x > syntax." > 3) "I think #[] will cause as many problems for such tools as @@, just in > different places." > > Maybe they weren't always as polite or succinct as that, but not agreeing > with you is not the same as not caring. > > > As far as I can make out, attributes that appear entirely on a single line > with no other text are trivial to ignore in any parser whatever the syntax. > That trivial case is slightly more trivial with #[] because a PHP 7 parser > will treat it as a line comment; but add a rule to your parser to also > treat "@@" as a line comment, and you're done. > > The problems come when you have a) an attribute definition spanning > multiple lines, and/or b) an attribute definition inline with other code. > As soon as you have that, you have no choice but to parse the code entirely > according to the grammar of PHP 8, not as "PHP 7 with some warts". > > If detecting the end of annotation tokens is really that difficult, would > it suffice to make the () mandatory (i.e. @@Deprecated() rather than > @@Deprecated)? The rules for what could appear between @@ and ( are pretty > simple, and finding the correct ending ) should be pretty much the same > effort as finding the correct ending ], since both can occur in matching > pairs inside the argument list. > > Regards, > -- > Rowan Tommins > [IMSoP]
-- Guilherme Blanco SVP Technology at Statflo Inc. Mobile: +1 647 232 5599
  111270
July 30, 2020 16:27 kontakt@beberlei.de (Benjamin Eberlei)
On Thu, Jul 30, 2020 at 6:19 PM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> Question: The key factor of not using @ is due to conflict of > suppression symbol. > While we are in a major (where BC breaks are not encourage, but > tolerable), have we considered the possibility of BC breaking > suppression symbol (@ would become @@) and using @ for Attributes? >
no chance, it needs at lesat 1 major release of deprecation before a syntax should be reusable for something else.
> > I bet a search/replace wouldn't be that hard to be achieved, and it > would function even today (as @@ is acceptable). Basically, it's a BC > break where code needs to be changed, but backwards compatible as new > suppressor symbol is backwards compatible with previous versions of > PHP. >
> Just some food for thought.... > > On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins collins@gmail.com> > wrote: > > > > On Thu, 30 Jul 2020 at 14:28, Joe Ferguson <joe@joeferguson.me> wrote: > > > > > ... I'm still here wanting us to talk about the > > > impact of @@ on static analysis tools. Apparently, internals doesn't > care > > > about these projects. > > > > > > > > > I don't think that's a reasonable summary of this thread at all. I've > seen > > three main types of response: > > > > 1) "I haven't followed the discussion about PHPCS, please could you > > summarise the problem." > > 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x > > syntax." > > 3) "I think #[] will cause as many problems for such tools as @@, just in > > different places." > > > > Maybe they weren't always as polite or succinct as that, but not agreeing > > with you is not the same as not caring. > > > > > > As far as I can make out, attributes that appear entirely on a single > line > > with no other text are trivial to ignore in any parser whatever the > syntax. > > That trivial case is slightly more trivial with #[] because a PHP 7 > parser > > will treat it as a line comment; but add a rule to your parser to also > > treat "@@" as a line comment, and you're done. > > > > The problems come when you have a) an attribute definition spanning > > multiple lines, and/or b) an attribute definition inline with other code. > > As soon as you have that, you have no choice but to parse the code > entirely > > according to the grammar of PHP 8, not as "PHP 7 with some warts". > > > > If detecting the end of annotation tokens is really that difficult, would > > it suffice to make the () mandatory (i.e. @@Deprecated() rather than > > @@Deprecated)? The rules for what could appear between @@ and ( are > pretty > > simple, and finding the correct ending ) should be pretty much the same > > effort as finding the correct ending ], since both can occur in matching > > pairs inside the argument list. > > > > Regards, > > -- > > Rowan Tommins > > [IMSoP] > > > > -- > Guilherme Blanco > SVP Technology at Statflo Inc. > Mobile: +1 647 232 5599 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  111271
July 30, 2020 16:29 rowan.collins@gmail.com (Rowan Tommins)
On Thu, 30 Jul 2020 at 17:18, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> > I bet a search/replace wouldn't be that hard to be achieved >
Find-and-replace always sounds like a good idea, until you realise that people run *a lot* of third-party code. I would not enjoy going through every Composer package in my vendor directory, checking for or supplying an appropriate patch, and then waiting for a tag or forking to create my own. Regards, -- Rowan Tommins [IMSoP]
  111272
July 30, 2020 16:31 guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")
On Thu, Jul 30, 2020 at 12:30 PM Rowan Tommins collins@gmail.com> wrote:
> > On Thu, 30 Jul 2020 at 17:18, guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com> wrote: > > > > > I bet a search/replace wouldn't be that hard to be achieved > > > > > Find-and-replace always sounds like a good idea, until you realise that > people run *a lot* of third-party code. I would not enjoy going through > every Composer package in my vendor directory, checking for or supplying an > appropriate patch, and then waiting for a tag or forking to create my own.
The beauty is that maintainers could release the packages today, and not wait for 8.0.0 to be released.
> > Regards, > -- > Rowan Tommins > [IMSoP]
-- Guilherme Blanco SVP Technology at Statflo Inc. Mobile: +1 647 232 5599
  111273
July 30, 2020 17:24 tysonandre775@hotmail.com (tyson andre)
Hi Joe Ferguson,

> Now that it seems the technical concerns around @@ have been resolved by > another pending, passing, RFC, I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. I care and I'm trying to help. I'm not trying to > revote until I get the vote I want. I'm just a dude that had some free time > while on vacation when he saw a chance to contribute.
3 commonly used static analyzers (for type inference) are - PHPStan and Psalm, both of which use nikic/php-parser. As Nikita Popov (the maintainer of php-parser) wrote,
> Emulating #[] lexing on older versions will > definitely be a challenge for PHP-Parser. I don't think we should make > concerns of external tooling hold us back too much, but the phpcs argument > really doesn't hold water.
Comparatively, it would be easy to join two adjacent `@` tokens to a single `@@` token in a single pass over token_get_all. Parsers would likely already do that or benefit from doing that for tokens such as the `match` token (T_MATCH) in php 8.0. Another commonly used static analyzer is Phan (https://github.com/phan/phan/) , which I am a maintainer of. My reasons for preferring `<<>>` or @@ over `#[` were mentioned in https://externals.io/message/111218#111239 . For phpcs and other linters, my belief is that this might be easier for simple use cases in the short term, but edge cases or ambiguities like multi-line attributes or refactorings that were safe in php 7 (such as moving `#[]` behind other tokens to another line) may cause issues for users of those tools (until those tools drop support for php 7.x and older). This is why I'd advocate for a distinct token that doesn't overlap with line comments Cheers, - Tyson
  111279
July 31, 2020 16:20 kaznovac@gmail.com (Marko Kaznovac)
HI,

[disclosure: I'm not php internals/interpreter developer; have ~10 years of
using php language]


I've searched but couldn't find in this discussion:

Can we keep the 'current' [doctrine/annotations or similar libraries]
annotation syntax and implement parsing of metadata in PHPinterpreter?
[something like having internal/native doctrine/annotations implementation
that can use opcache]

pros:
- existing tooling will continue to work
- existing code will continue to work - no need for developers to migrate
their code
- no need for developers to learn new syntax

cons:
- code comments cannot be removed from opcache :| [or can they? if
metadata/annotations get parsed and attached in preload - comments can be
discarded if not needed in runtime]


I'm sorry if I've added some noise by missing something that's obvious; I
would really appreciate it if someone from the php internal comments on
this.


cheers,
k


On Thu, Jul 30, 2020 at 7:24 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> Hi Joe Ferguson, > > > Now that it seems the technical concerns around @@ have been resolved by > > another pending, passing, RFC, I'm still here wanting us to talk about > the > > impact of @@ on static analysis tools. Apparently, internals doesn't care > > about these projects. I care and I'm trying to help. I'm not trying to > > revote until I get the vote I want. I'm just a dude that had some free > time > > while on vacation when he saw a chance to contribute. > > 3 commonly used static analyzers (for type inference) are > - PHPStan and Psalm, both of which use nikic/php-parser. As Nikita Popov > (the maintainer of php-parser) wrote, > > > Emulating #[] lexing on older versions will > > definitely be a challenge for PHP-Parser. I don't think we should make > > concerns of external tooling hold us back too much, but the phpcs > argument > > really doesn't hold water. > > Comparatively, it would be easy to join two adjacent `@` tokens to a > single `@@` token in a single pass over token_get_all. > Parsers would likely already do that or benefit from doing that for tokens > such as the `match` token (T_MATCH) in php 8.0. > > Another commonly used static analyzer is Phan ( > https://github.com/phan/phan/) , which I am a maintainer of. > My reasons for preferring `<<>>` or @@ over `#[` were mentioned in > https://externals.io/message/111218#111239 . > > For phpcs and other linters, my belief is that this might be easier for > simple use cases in the short term, > but edge cases or ambiguities like multi-line attributes or refactorings > that were safe in php 7 > (such as moving `#[]` behind other tokens to another line) > may cause issues for users of those tools (until those tools drop support > for php 7.x and older). > This is why I'd advocate for a distinct token that doesn't overlap with > line comments > > Cheers, > - Tyson > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  111265
July 30, 2020 13:59 tysonandre775@hotmail.com (tyson andre)
Hi Benjamin,

> The reason is not only Joe's desire to revote on #[], but also that there > are now more syntax proposals such as @[] by Derick or @@ in comments by > Tyson (though no patch exists for it yet). At this point a lot of syntaxes > are potentially viable (except single @, please don't suggest it).
I'd agree, I mentioned earlier that I'd preferred ranked choice over a 2-choice vote. Unrelatedly, https://wiki.php.net/rfc/shorter_attribute_syntax_change does not mention the drawbacks I've mentioned about significantly changing lexing in unexpected ways (`#Attr('?>')` will start inline HTML in php 7). People reading the RFC might expect that `#[` would only lead to missing tokens, not significantly different tokens. - https://externals.io/message/111218#111239 P.S. I don't plan to create a patch for attributes in comments due to the long-term drawbacks for those writing tooling/editors for it,  difficulty to learn it, increased complexity of the implementation, etc. I'd strongly prefer `<<` and `@@` over comments-based syntax. That was more of "if language designers really, really wanted to write attributes syntax that would be usable immediately and work with existing tools, ignoring various drawbacks elsewhere, then what could they implement?" I don't have objections to anyone attempting to implement it, but I'm not going to push for it/work on it. Cheers, - Tyson
  111281
August 2, 2020 15:11 derick@php.net (Derick Rethans)
On Thu, 30 Jul 2020, Benjamin Eberlei wrote:

> I think it has become clear that we need to revisit this syntax question > again, including the elephpant in the room of delaying this feature to 8.1. > > The reason is not only Joe's desire to revote on #[], but also that there > are now more syntax proposals such as @[] by Derick or @@ in comments by > Tyson (though no patch exists for it yet). At this point a lot of syntaxes > are potentially viable (except single @, please don't suggest it). > > I feel the choice between many syntaxes is 80% subjective, 20% objective > facts, so tensions are to be expected. > > As the author of the original RFC and patch, I hope I have some klout in > suggesting the following procedure (RMs would need to extend their approval > for revote to this).
This seems like a sensible solution. 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
  111288
August 2, 2020 22:40 joe@joeferguson.me (Joe Ferguson)
On Sun, Aug 2, 2020 at 10:11 AM Derick Rethans <derick@php.net> wrote:

> On Thu, 30 Jul 2020, Benjamin Eberlei wrote: > > > I think it has become clear that we need to revisit this syntax question > > again, including the elephpant in the room of delaying this feature to > 8.1. > > > > The reason is not only Joe's desire to revote on #[], but also that there > > are now more syntax proposals such as @[] by Derick or @@ in comments by > > Tyson (though no patch exists for it yet). At this point a lot of > syntaxes > > are potentially viable (except single @, please don't suggest it). > > > > I feel the choice between many syntaxes is 80% subjective, 20% objective > > facts, so tensions are to be expected. > > > > As the author of the original RFC and patch, I hope I have some klout in > > suggesting the following procedure (RMs would need to extend their > approval > > for revote to this). > > This seems like a sensible solution. > > cheers, > Derick >
Sounds good to me as well. I'll update this RFC to Declined. Thanks, everyone for the discussion and everyone who reviewed the RFC and gave feedback on ideas and code examples. -- - Joe Ferguson JoeFerguson.me osmihelp.org