# [VOTE] Shorter Attribute Syntax Change - Thread: https://externals.io/message/111416 - Original archive: https://news-web.php.net/php.internals/111416 - Started by Derick Rethans on 2020-08-10T08:41:09+00:00 - Messages: 118 - RFC: Shorter Attribute Syntax Change (Implemented (PHP 8.0)) — https://externals.io/rfc/shorter_attribute_syntax_change.md - Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/111416.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #111416 — Derick Rethans — 2020-08-10T08:41:09+00:00 URL: https://externals.io/message/111416#111416 Hi, I've just opened the vote to make sure we don't make a terrible mistake with using the @@ syntax for attributes: https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting The first vote is a vote to say that you have an opinion about attribute syntax. Make sure to read up on the discussion on the mailinglist if you haven't done so yet. The second vote is an STV vote. In STV you SHOULD rank *all* choices, but don't pick the same one more than once, as that will invalidate your vote. Please have a objective look at the table (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and don't just go by asthetics. The vote ends August 23, 24:00 UTC. 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 --- ## #111417 — Rowan Tommins — 2020-08-10T09:15:25+00:00 URL: https://externals.io/message/111416#111417 · In reply to: #111416 > I've just opened the vote to make sure we don't make a terrible mistake > with using the @@ syntax for attributes: > > [...] > > Please have a objective look at the table > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and > don't just go by asthetics. > Hi Derick, I am not a fan of the @@ syntax, and respect what you're trying to do with this RFC, but am disappointed you haven't engaged with those of us who said that the RFC needs more detail. There is simply not enough information in that table to "have an objective look", and the only other text in the RFC makes a vague assertion about the lack of ending symbol which I still don't understand the significance of. If I had a vote, I would vote "No" in the primary vote, not because I think the current syntax is perfect, but because I don't think this RFC makes a good case for a revote, and strongly suspect it will just be another beauty contest. Regards, -- Rowan Tommins [IMSoP] --- ## #111418 — Peter Bowyer — 2020-08-10T09:27:39+00:00 URL: https://externals.io/message/111416#111418 · In reply to: #111417 > I am not a fan of the @@ syntax, and respect what you're trying to do with > this RFC, but am disappointed you haven't engaged with those of us who said > that the RFC needs more detail. There is simply not enough information in > that table to "have an objective look", and the only other text in the RFC > makes a vague assertion about the lack of ending symbol which I still don't > understand the significance of. > I have voted no because I asked a question about the ending delimiter and why () didn't count. Another person asked a similar question and neither of us got a reply. Peter --- ## #111422 — Jordi Boggiano — 2020-08-10T11:32:13+00:00 URL: https://externals.io/message/111416#111422 · In reply to: #111416 > I've just opened the vote to make sure we don't make a terrible mistake > with using the @@ syntax for attributes: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting > Here is a more detailed comparison of how this would look like in real use, adapted from some basic doctrine and symfony validation annotation I got somewhere: https://gist.github.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c I think something like this would belong in the RFC. I find that the grouping "feature" does not help that much, it's kinda hard to grasp what's going on. Proper syntax highlighting would surely help but still. You may argue it's comparing in terms of looks, but as others have said I find it hard to compare them in other terms as the pros/cons listed in the RFC have a very limited impact for the most part, so yeah I feel like looks and readability should be at least somewhat taken into account too. Best, Jordi --- ## #111423 — Benjamin Eberlei — 2020-08-10T12:09:49+00:00 URL: https://externals.io/message/111416#111423 · In reply to: #111417 On Mon, Aug 10, 2020 at 11:16 AM Rowan Tommins wrote: > > > > […] > > > Hi Derick, > > I am not a fan of the @@ syntax, and respect what you're trying to do with > this RFC, but am disappointed you haven't engaged with those of us who said > that the RFC needs more detail. There is simply not enough information in > that table to "have an objective look", and the only other text in the RFC > makes a vague assertion about the lack of ending symbol which I still don't > understand the significance of. > > If I had a vote, I would vote "No" in the primary vote, not because I think > the current syntax is perfect, but because I don't think this RFC makes a > good case for a revote, and strongly suspect it will just be another beauty > contest. > I am sorry this was a misunderstanding between Derick and I. I had worked on the more detail already, but we had a miscommunication about updating the RFC. I add my notes in a few minutes, sorry :-( > > Regards, > -- > Rowan Tommins > [IMSoP] --- ## #111424 — Markus Fischer — 2020-08-10T13:05:27+00:00 URL: https://externals.io/message/111416#111424 · In reply to: #111422 > https://gist.github.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c This is really really useful! However I suggest to look at the raw text rather, because the highlighting is unaware of the syntax and may bias "how it feels to look at it" (*): https://gist.githubusercontent.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c/raw/ccb612d2547c99fe69d1bf09138efae22b956b37/attributes.php Personally, and never gave it much thought TBH, the `@@` AND `<<`/`>>` in fact is the most "unreadable" version to me because duplicate occurrence of a single character somehow creates a noise _for me_, I don't feel eligible to have a vote, but based on that and certainly aware IDEs in the future will help with this, I would vote for _anything_ not duplicating characters, i.e. favoring `#[]` or `@[]` :-} - Markus (*) Apologies for lack of words trying to describe my thoughts --- ## #111425 — Benjamin Eberlei — 2020-08-10T13:08:26+00:00 URL: https://externals.io/message/111416#111425 · In reply to: #111418 On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer wrote: > On Mon, 10 Aug 2020 at 10:15, Rowan Tommins > wrote: > > > […] > with > > […] > said > > […] > RFC > > […] > don't > > […] > > I have voted no because I asked a question about the ending delimiter and > why () didn't count. Another person asked a similar question and neither of > us got a reply. > () does not count as ending symbol, because it is not required, as such its not an ending symbol. The point Andreas Leathley makes in the discussion thread about new Foo not having an end symbol demonstrates exactly the opposite point he was trying to make, because the new statement itself has to end with a semicolon: new Foo(); new Foo; A statement has an ending symbol semicolon. Yes you can argue an attribute is metadata like "public" or "static" and they don't have start and ending symbols either. But they are also *single* words without special chars, as such much easier to distinguish. The difference is also apparent in another fact: Visibility keywords are just boolean flags on Reflection, Attributes have their own Reflection object, they represent much more. They shouldn't be mixed up with keywords. PHP is a language where most language constructs have ending delimiters. - Statements end in Semicolon - Function/Class/Method declarations end with a block closed by } - Argument lists end with ) - Docblocks end with */ - Comments always end with EOL (the distinction here being its a single end symbol, not ambiguous) As such for language consistency it would be better for Attributes to be enclosed by syntax, having a start **and* and ending symbol. > Peter --- ## #111426 — Theodore Brown — 2020-08-10T13:27:56+00:00 URL: https://externals.io/message/111416#111426 · In reply to: #111416 > I've just opened the vote to make sure we don't make a terrible mistake > with using the @@ syntax for attributes: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting > > The first vote is a vote to say that you have an opinion about attribute > syntax. Make sure to read up on the discussion on the mailinglist if you > haven't done so yet. I voted "No", as the primary premise for this RFC is fundamentally flawed: > The main concern is that @@ has no ending symbol and it's inconsistent > with the language that it would be the only declaration or statement > in the whole language that has no ending termination symbol. As I pointed out in the discussion thread, this simply is not the case. Attributes are not standalone declarations or statements, but modifiers that always come before a declaration and add metadata to it. This is consistent with visibility modifiers and type declarations (which are not necessarily a single word): # declaration modifiers do not have end/grouping symbols like this @[MyAttr([1, 2])] [public] function foo(@[Deprecated] [int|float] $bar) {} # this is more consistent: @@MyAttr([1, 2]) public function foo(@@Deprecated int|float $bar) {} > The second vote is an STV vote. > > In STV you SHOULD rank *all* choices, but don't pick the same one more > than once, as that will invalidate your vote. > > Please have a objective look at the table > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and > don't just go by asthetics. I find this table to be unfortunately incomplete. E.g. why doesn't it bold the number of required characters for @@, since this is one of its advantages? And why is "Allows Grouping" marked as an advantage for the other three syntaxes? Grouping adds implementation complexity, leads to unnecessary diff noise, and is rarely more concise than @@ in real-world use cases. I also find it concerning that the RFC doesn't have an example for each consideration showing how one syntax addresses it better than another. For example, the Shorter Attribute Syntax RFC showed potential nested attributes and how @@ would support them more cleanly, but this RFC fails to mention them anywhere. Finally, while the table mentions that each syntax other than <<>> has a BC break, I think it's just as important to consider the *size* of the breaking change. #[] and @[] are larger BC breaks than @@ since they break useful syntax: // with #[] #[x] code like this would break $val = ['new value']; #['old value']; // with @[] $x = @[foo(), bar()]; // this code would break Both of these are useful patterns, and I'm not convinced that breaking them is justified. Shouldn't there be a Backward Incompatible Changes section in the RFC with these examples? Best regards, Theodore --- ## #111427 — Andreas Leathley — 2020-08-10T13:33:38+00:00 URL: https://externals.io/message/111416#111427 · In reply to: #111425 > () does not count as ending symbol, because it is not required, as > such its > not an ending symbol. > > The point Andreas Leathley makes in the discussion thread about new Foo not > having an end symbol demonstrates exactly the opposite point he was trying > to make, because the new statement itself has to end with a semicolon: > > new Foo(); > new Foo; > > A statement has an ending symbol semicolon. While I don't know the exact internal semantics of PHP, according to my grasp of the language the new keyword does not need a semicolon at the end - it can be part of any expression, like "new Foo(new Bar);". According to the PHP manual (https://www.php.net/manual/en/language.basic-syntax.instruction-separation.php) instructions in PHP need to be terminated with a semicolon, while "new" as a keyword has no special requirement about a starting or ending delimiter. The point I was trying to make was that new and attributes have the same requirements in that they both need a class name and then optionally arguments for the constructor to that class, so they are both narrow in terms of what they do, attributes even more so than new, which reduces the helpfulness of delimiters as you cannot define arbitrary instructions in attributes - it always starts off with a class and then any possibly more complex instructions will be in the arguments, and those are enclosed by (). --- ## #111428 — Rowan Tommins — 2020-08-10T13:39:46+00:00 URL: https://externals.io/message/111416#111428 · In reply to: #111425 > > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer > wrote: > > > […] > > () does not count as ending symbol, because it is not required, as such > its not an ending symbol. > The question asked was that _if the parentheses were made mandatory_, would this provide the same benefits ascribed to the other syntaxes? To avoid repeating myself, here are the previous posts where I elaborated on this question: * https://externals.io/message/111312#111342 * https://externals.io/message/111312#111354 Regards, -- Rowan Tommins [IMSoP] --- ## #111430 — guilhermeblanco@gmail.com — 2020-08-10T13:52:14+00:00 URL: https://externals.io/message/111416#111430 · In reply to: #111428 Hi, One question I'd like answered is that, like me, a few people have voted NO on the question to re-vote the syntax. If that is true, shouldn't their first primary choice be implied to be <<>> instead of anything else? I see 7 votes for no, but I'm the only one that still kept the first voting choice as <<>>. > > > > > […] > > > The question asked was that _if the parentheses were made mandatory_, would > this provide the same benefits ascribed to the other syntaxes? > > To avoid repeating myself, here are the previous posts where I elaborated > on this question: > > * https://externals.io/message/111312#111342 > * https://externals.io/message/111312#111354 > > > Regards, > -- > Rowan Tommins > [IMSoP] -- Guilherme Blanco SVP Technology at Statflo Inc. Mobile: +1 647 232 5599 --- ## #111433 — Benjamin Eberlei — 2020-08-10T13:56:02+00:00 URL: https://externals.io/message/111416#111433 · In reply to: #111428 On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins wrote: > On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei > wrote: > > > […] > and > > […] > > > The question asked was that _if the parentheses were made mandatory_, would > this provide the same benefits ascribed to the other syntaxes? > > To avoid repeating myself, here are the previous posts where I elaborated > on this question: > > * https://externals.io/message/111312#111342 > * https://externals.io/message/111312#111354 For me It would indeed make a slight difference, but not wanting to speak for Theodore, I believe he did not want to add this as another option to vote upon, when I asked him. based on the argument that new also doesn't require () it makes sense to me. And for me I didn't want to add it, because then we can just go back to <<>>, which would at least be symmetrical. I.e. @@Jit() vs <> > > > > Regards, > -- > Rowan Tommins > [IMSoP] --- ## #111432 — Andreas Leathley — 2020-08-10T13:56:26+00:00 URL: https://externals.io/message/111416#111432 · In reply to: #111424 > Personally, and never gave it much thought TBH, the `@@` AND `<<`/`>>` > in fact is the most "unreadable" version to me because duplicate > occurrence of a single character somehow creates a noise _for me_, > > I don't feel eligible to have a vote, but based on that and certainly > aware IDEs in the future will help with this, I would vote for > _anything_ not duplicating characters, i.e. favoring `#[]` or `@[]` It is a pity that syntax with ending delimiters and syntax with no ending delimiters are now mixed in the discussion, instead of first finding a concensus if delimiters are even needed or what advantages/disadvantages they have. Because there are many alternatives in terms of syntax - looking back at the very first vote about attributes the @: syntax doesn't seem so bad, if no ending delimiters are needed. In the new RFC all alternatives to @@ have delimiters and it is suggested having them is good, yet the possible advantages of delimiters are never explained, ideally with some real-world examples showing why delimiters would be good to have. --- ## #111435 — Benjamin Eberlei — 2020-08-10T13:58:17+00:00 URL: https://externals.io/message/111416#111435 · In reply to: #111430 On Mon, Aug 10, 2020 at 3:52 PM guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > Hi, > > One question I'd like answered is that, like me, a few people have > voted NO on the question to re-vote the syntax. > If that is true, shouldn't their first primary choice be implied to be > <<>> instead of anything else? I see 7 votes for no, but I'm the only > one that still kept the first voting choice as <<>>. > At this point voting NO on the primary vote means that you are either: 1. are not ok with revolting this late in the release cycle 2. want to keep @@, because this is the current syntax (not <<>>) > On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins > wrote: > > […] > wrote: > > […] > phpmailinglists@gmail.com> > > […] > and > > […] > neither > > […] > would > > […] > > > > -- > Guilherme Blanco > SVP Technology at Statflo Inc. > Mobile: +1 647 232 5599 > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #111436 — Derick Rethans — 2020-08-10T13:58:46+00:00 URL: https://externals.io/message/111416#111436 · In reply to: #111418 > > > > […] > > I have voted no because I asked a question about the ending delimiter and > why () didn't count. Another person asked a similar question and neither of > us got a reply. I did answer that as a reply to Rowan: https://externals.io/message/111312#111346 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 --- ## #111437 — Benas IML — 2020-08-10T14:02:08+00:00 URL: https://externals.io/message/111416#111437 · In reply to: #111426 > > > > […] > > I voted "No", as the primary premise for this RFC is fundamentally flawed: > > > […] > > As I pointed out in the discussion thread, this simply is not the case. > Attributes are not standalone declarations or statements, but modifiers > that always come before a declaration and add metadata to it. This > is consistent with visibility modifiers and type declarations (which > are not necessarily a single word): > > # declaration modifiers do not have end/grouping symbols like this > @[MyAttr([1, 2])] > [public] function foo(@[Deprecated] [int|float] $bar) {} > > # this is more consistent: > > @@MyAttr([1, 2]) > public function foo(@@Deprecated int|float $bar) {} > > > […] > > I find this table to be unfortunately incomplete. E.g. why doesn't it > bold the number of required characters for @@, since this is one of > its advantages? And IMO there's literally no advantage in typing one less character. Because if there is, let's also shorten all of our function names i. e. `strlen` to `sl` and `gettype` to `gt`. why is "Allows Grouping" marked as an advantage > for the other three syntaxes? Grouping adds implementation complexity, > leads to unnecessary diff noise, and is rarely more concise than @@ in > real-world use cases. > I'd like to remind other internals that there is no "added complexity" (unless someone is unable to understand 20 lines of code) and it's misleading to say otherwise. > I also find it concerning that the RFC doesn't have an example for each > consideration showing how one syntax addresses it better than another. > For example, the Shorter Attribute Syntax RFC showed potential nested > attributes and how @@ would support them more cleanly, but this RFC > fails to mention them anywhere. Syntax choice DOES NOT affect how "cleanly" we can support nested attributes. AFAIK simple recursion would allow to implement those with any attribute syntax with exactly the same code. > Finally, while the table mentions that each syntax other than <<>> has > a BC break, I think it's just as important to consider the *size* of > the breaking change. #[] and @[] are larger BC breaks than @@ since > they break useful syntax: > > // with #[] > #[x] code like this would break > $val = ['new value']; #['old value']; > > // with @[] > $x = @[foo(), bar()]; // this code would break > > Both of these are useful patterns, and I'm not convinced that breaking > them is justified. Shouldn't there be a Backward Incompatible Changes > section in the RFC with these examples? > > Best regards, > Theodore > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #111438 — Rowan Tommins — 2020-08-10T14:39:15+00:00 URL: https://externals.io/message/111416#111438 · In reply to: #111433 > > On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins > wrote: > > > […] > > For me It would indeed make a slight difference... > Sorry, I'm as confused by this answer as I was by Derick's. Is that a "yes, it would solve the same problems", or "it would solve some problems but not others"? Regards, -- Rowan Tommins [IMSoP] --- ## #111439 — Peter Bowyer — 2020-08-10T14:41:37+00:00 URL: https://externals.io/message/111416#111439 · In reply to: #111436 > I did answer that as a reply to Rowan: > > https://externals.io/message/111312#111346 I'm with Rowan's response to you: https://externals.io/message/111312#111354 What is the difference between mandatory parentheses giving: <><>( <><>(<>), 42 ) and: <>[<>( <>[<>(<>)], 42 )] in terms of parsing, use etc. Peter --- ## #111442 — Derick Rethans — 2020-08-10T15:40:56+00:00 URL: https://externals.io/message/111416#111442 · In reply to: #111432 > > > […] > > It is a pity that syntax with ending delimiters and syntax with no > ending delimiters are now mixed in the discussion, instead of first > finding a concensus if delimiters are even needed or what > advantages/disadvantages they have. It missing an ending delimiter was my first reason for wanting to get something better than @@. I don't particularly care much if it ends up being @[], #[], <<>>, or other things such as @:( ). In my original email, I solicited other syntaxes (with patches), but none were brought up. > Because there are many alternatives in terms of syntax - looking back > at the very first vote about attributes the @: syntax doesn't seem so > bad, if no ending delimiters are needed. In the new RFC all > alternatives to @@ have delimiters and it is suggested having them is > good, yet the possible advantages of delimiters are never explained, > ideally with some real-world examples showing why delimiters would be > good to have. If you have something to open, and close, there there is a distinct area that forms the whole definition of a thing. That's why functions, and classes have { and }, if and other control structures have ( .. ), etc. Being able to define a whole "thing" easily with an open and closing set of symbols, allows for better mental parsing. It also means that syntax highlighting tools can map the opening part with the closing part. (VIM for example, uses the % character to jump between opening and closing symbol). 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 --- ## #111444 — Andreas Leathley — 2020-08-10T16:27:55+00:00 URL: https://externals.io/message/111416#111444 · In reply to: #111442 > It missing an ending delimiter was my first reason for wanting to get > something better than @@. I don't particularly care much if it ends up > being @[], #[], <<>>, or other things such as @:( ). > > If you have something to open, and close, there there is a distinct area > that forms the whole definition of a thing. That's why functions, and > classes have { and }, if and other control structures have ( .. ), etc. > > Being able to define a whole "thing" easily with an open and closing set > of symbols, allows for better mental parsing. It also means that syntax > highlighting tools can map the opening part with the closing part. (VIM > for example, uses the % character to jump between opening and closing > symbol). For me the difference would be that with attributes, you are not opening and closing many possible statements, it can only be one (or more, with grouping) class name(s), which then can have arguments, but those are enclosed with (). In comparison, classes can have many possible definitions inside of them (class variables, methods, constants, etc.), so enclosing them clearly makes sense, as you need to know where it ends. The same goes for if, for, while, etc. So if you just have one class name as an attribute, enclosing it seems a bit overkill, as there is already a definition of a class name and how it starts and ends, which is why for me the mental parsing does not seem easier - but what is easily parseable probably depends on many factors and might be different for different people. I would have found a syntax where the delimiters are optional preferable - similar to "if", where you can leave off the {} for exactly one instruction, but you have to add them if there is more than one line of instructions. Or the group use syntax. --- ## #111450 — Chris Riley — 2020-08-11T10:10:13+00:00 URL: https://externals.io/message/111416#111450 · In reply to: #111416 Hi, Quick question. What is the expected behaviour of: @[Bar()]; class Foo {} That would appear to be valid code and for the difference of a single ; does wildly different things, assuming there is a function Bar defined somewhere. (and only by the fact that @ doesn't suppress fatal errors does it not cause utter confusion if Bar isn't defined) Regards, Chris > Hi, > > I've just opened the vote to make sure we don't make a terrible mistake > with using the @@ syntax for attributes: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting > > The first vote is a vote to say that you have an opinion about attribute > syntax. Make sure to read up on the discussion on the mailinglist if you > haven't done so yet. > > The second vote is an STV vote. > > In STV you SHOULD rank *all* choices, but don't pick the same one more > than once, as that will invalidate your vote. > > Please have a objective look at the table > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and > don't just go by asthetics. > > The vote ends August 23, 24:00 UTC. > > cheers, > Derick > > -- > PHP 7.4 Release Manager > Host of PHP Internals News: https://phpinternals.news > Like Xdebug? Consider supporting me: https://xdebug.org/support > https://derickrethans.nl | https://xdebug.org | https://dram.io > twitter: @derickr and @xdebug > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #111456 — Matteo Beccati — 2020-08-11T11:40:21+00:00 URL: https://externals.io/message/111416#111456 · In reply to: #111450 Hi, > What is the expected behaviour of: > > @[Bar()]; > class Foo {} > > That would appear to be valid code and for the difference of a single ; > does wildly different things, assuming there is a function Bar defined > somewhere. (and only by the fact that @ doesn't suppress fatal errors does > it not cause utter confusion if Bar isn't defined) I think an 'unexpected token ";"', which is what currently happens if you do the same with "@@" on current master, would still be an appropriate behaviour. FWIW, I haven't made up my mind yet and that's why I haven't cast my vote yet. I do agree with Chris here and I somehow mentally parse the above as "silencing an array containing a function call", which to me is bad enough to rule the syntax out. I would surely get used to it, if accepted, but that's how I feel now. Rust's #[] to me looks better, but I am still bothered by the fact that it can be used in a backwards compatible way, but not fully so (multi-line, syntax errors). And "@@" is super ugly, although I'm not bothered that much by its lack of ending delimiter, since most of the times longer attributes will still, albeit just visually, have some in the closing ")". Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #111457 — Chris Riley — 2020-08-11T11:50:24+00:00 URL: https://externals.io/message/111416#111457 · In reply to: #111456 > Hi, > > > > […] > does > > […] > I think an 'unexpected token ";"', which is what currently happens if > you do the same with "@@" on current master, would still be an > appropriate behaviour. > > FWIW, I haven't made up my mind yet and that's why I haven't cast my > vote yet. > > I do agree with Chris here and I somehow mentally parse the above as > "silencing an array containing a function call", which to me is bad > enough to rule the syntax out. I would surely get used to it, if > accepted, but that's how I feel now. > > Rust's #[] to me looks better, but I am still bothered by the fact that > it can be used in a backwards compatible way, but not fully so > (multi-line, syntax errors). > > And "@@" is super ugly, although I'm not bothered that much by its lack > of ending delimiter, since most of the times longer attributes will > still, albeit just visually, have some in the closing ")". > > > Cheers > -- > Matteo Beccati > > Development & Consulting - http://www.beccati.com/ My concern wasn't so much of mentally parsing it as a silenced function call in an array; more that PHP currently parses it that way. That example becoming invalid code would be a reasonable option, but leaving it as valid code just sets people up to spend ages hunting a "why is this annotation not being applied to my class bug". (and before anyone says this won't happen; I have spent hours in the past tracking down missing annotations which occured because of the difference between /* and /**) For the record, my preference is @[ ], I just also like removing as many potential cases of debugging stupid issues as possible. ~C --- ## #111459 — Derick Rethans — 2020-08-11T12:21:57+00:00 URL: https://externals.io/message/111416#111459 · In reply to: #111450 > Quick question. > > What is the expected behaviour of: > > @[Bar()]; > class Foo {} That will error out in PHP 8, with: Parse error: syntax error, unexpected token ";" in Standard input code on line 2 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 --- ## #111460 — Chris Riley — 2020-08-11T12:26:42+00:00 URL: https://externals.io/message/111416#111460 · In reply to: #111459 > > > > […] > > That will error out in PHP 8, with: > > Parse error: syntax error, unexpected token ";" in Standard input code on > line 2 > > 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 > Is on it's own an error? --- Next page: https://externals.io/message/111416.md?page=2