On Mon, Aug 17, 2020 at 2:29 PM Benjamin Eberlei <kont...@beberlei.de> wrote:
> > > On Mon, Aug 17, 2020 at 10:02 AM Peter Bowyer <rey...@php.net> wrote: > >> On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei <kont...@beberlei.de> >> wrote: >> >>> We have updated the RFC at >>> https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we >>> think >>> covers all the discussion and arguments made in this and the previous >>> mailing list threads. >>> >> >> Thank you for putting in the work it took to revise the RFC. It's good. I >> now understand what the delimiters achieve. >> >> While I don't agree with the first point in "Forcing @@ Attributes to end >> with parenthesis does not solve issues" (in this new syntax I'd ban >> whitespace) I appreciate the point you are making, and it is sensible for >> consistency. >> >> I feel grep'ability has been played down, as unless >> @@ >> MyProject\FooAttr >> >> is allowed (which isn't shown in the codeblock), then it's easier to grep >> for @@.+?Foo and know you have a chance of an accurate match (assuming >> renaming is not used) than it is with the delimiter syntax. >> > > no space is allowed between @@ and name, they have to be in the same line. > The whitespace between name and argument_list is not currently banned, the > comparison is to the status quo (since that is not expected to change). > Correction, I was made aware that this is not true, a space betwen @@ and attribute name is allowed at the moment: @@ MyProject\FooAttr function foo() {} is allowed. > > Still I think the grepability has to rest on no assumptions, because > otherwise you could argue the same for @[] being used non-grouped on one > line and would have to conclude that this is also grepable. > >> >> Sorry to everyone for causing this hazzle. >>> >> >> These things happen. Thank you for taking on-board the feedback and >> working on the RFC. >> >> Peter >> >
