Re: [RFC] Shorter attribute syntax

On Mon, June 8, 2020 at 10:01 AM Larry Garfield <larry@garfieldtech.com> wrote: > FWIW, I find both alternatives ugly to my eye. So, there's that. > > Given that @ is off the table for obvious reasons, my > preference > would frankly be for Rust's #[], which has the nice side > effect > of being a normal comment in earlier PHP versions and so attributes > can be included as optional without breaking BC. I don't know if > that's a big deal or not, but it's a benefit. And it should be no > harder on the parser to differentiate than @ vs > @@ is. > > (The only advantage of @@ in my mind is another obvious Star > Wars > joke.) Hi Larry, From the perspective of looks I don't have a strong preference between them. There are two main reasons I decided against borrowing the #[] syntax from Rust: 1. It's a much larger BC break. Disallowing comments from starting with a certain character could break a lot of code in the wild. From a quick search of grep.app, I found two examples on the first page of results using #[ as a comment. [1] Is it worth breaking this code? 2. #[] is slightly more verbose, which works against one of the objectives of the RFC. Rust is the only language I found that uses three characters for its attribute syntax like this. I actually starting trying to draft an RFC which would propose the #[] syntax for attributes, but one thing I noticed while doing so is that (at least on my QWERTY keyboard) #[ is noticeably harder to type - I kept typoing it as #] or #\. This is dependent on keyboard layout, of course, but being prone to accidental typos was also one of the arguments against the @: syntax in the original RFC. > Something that I don't think has been addressed explicitly in this > thread yet is single line vs separate line attributes. Vis: > > <<Foo>> class Blah {} > > vs. > > ```php > <<Foo>> > class Blah {} > ``` > > Syntactically both are legal AFAIK; I don't know which most people > will do. The separate line version seems more likely, and cleaner > to me, but for parameters people may want to inline it in shorter > signatures. Or it may push people to always multi-line those > function definitions, for better or worse. (I find that quite ugly > myself, but I don't know if I'm in the majority on that view.) > > My gut feeling is that @@ is notably worse inline. It > subjectively > feels messier because there's no clear indication of where the end > is. On separate lines, @@ and << > >> seem about equally ugly to me. Personally I have the opposite reaction when it comes to inline parameter attributes - the closing >> always looks like a shift operator at first glance which makes it harder for me to read. And for an inline function or class attribute the function/class keyword already provides a strong indication of where the attribute ends. But for anything other than very short attributes, I expect most people will want to put the attribute on a separate line for optimal readability, regardless of the final syntax: ```php function foo( <<ExampleAttribute("foo", "bar")>> <<OtherAttribute(123, ["key" => "val"])>> Type $myParam, bool $param2, ) { ... } // vs. function foo( @@ExampleAttribute("foo", "bar") @@OtherAttribute(123, ["key" => "val"]) Type $myParam, bool $param2, ) { ... } ``` Best regards, Theodore [1]: https://grep.app/search?q=%23%5B&filter[lang][0]=PHP