On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans <der...@php.net> wrote:
> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
