[RFC] Shorter attribute syntax

Hello, yes, that would create ambiguity in the parser since `#` (just like `//`) is for comments. Best regards, Benas On Thu, Jun 4, 2020, 11:03 AM Peter Bowyer <phpmailinglists@gmail.com> wrote:

On Thu, June 4, 2020 at 6:55 AM Jordi Boggiano <j.boggiano@seld.be> wrote: > Thanks for the write-up. I didn't feel strongly either way before but > after reading the RFC I am hoping it passes. > > Another fringe benefit is the ability to grep for attributes, @@ does > not occur anywhere in a couple projects I checked, while << does occur > both as the << operator and heredocs/nowdocs. My fellow > grumpy-old-non-IDE-users might find this a valid argument too :) Hi Jordi, That's a good point. I have updated the RFC to briefly mention this benefit as well. Best regards, Theodore

On Thu, June 4, 2020 at 12:19 PM Rowan Tommins <rowan.collins@gmail.com> wrote: > Hi Theodore, Hi Rowan, Thanks for the feedback. I added replies inline. > I find the "objective" reasons in this RFC to be greatly exaggerated. > > 1. `@@Jit` does not require "half as many characters" as `<<Jit>>`; > even for this, which is probably the shortest attribute anyone will > ever use, the saving is less than 30%; for more common attributes > which resemble entire function calls, it will be a tiny proportional > saving. By "half as many characters" the RFC is referring to the attribute syntax itself, not the name/arguments of the attribute being used. You're right that with longer attributes, the attribute syntax makes up a smaller percentage of the code. However, I'd argue the savings still has value even when it's a smaller proportion. > 2. You don't actually explain why `@@Foo` would be any easier to > integrate with nested attributes than `<<Foo>>`. Is there some > parser conflict that applies to one and not the other? Martin can correct me if I'm wrong here, but I believe nested attributes are syntactically possible with the `<<>>` syntax, but "ugly as sin" (to quote Nikita). For example: ```php <<JoinTable( "User_Group", <<JoinColumn("User_id", "id")>>, <<JoinColumn("Group_id", "id")>>, )>> private $groups; ``` Also, grouped attributes would probably have to be special-cased to be disallowed in nested attributes, since they don't make sense there. During implementation a bunch of work was put into trying to support nested attributes with `new` (e.g. `new JoinColumn("User_id", "id")`), but as the RFC mentions this was given up on since it turned out to be very difficult to implement and would require lots of changes to const expressions. > 3. While confusion with generics is possible, I would be interested > to hear from C# programmers how often they confuse `[Attribute]` for > an array index operation, or any of the other uses of square brackets. One reason I think confusion with generics is more probable is that generics and attributes would frequently be used in a similar location (near the start of a class declaration). > 4. Similarly, I've yet to see anyone point to an example of confusion > with shift operators that's not extremely contrived. I could come up > with equally contrived examples where an attribute contained e-mail > addresses and twitter handles, making `@@` look confusing. Perhaps, though this seems much less likely since email addresses and twitter handles would be in a string, whereas `<<` is a standalone token used outside of strings. > 5. No other language has been put forward using the `@@` operator. It > more closely resembles those languages that use a single `@`, but the > `<<Foo>>` syntax more closely resembles those languages that use some > form of brackets. Fair enough. This doesn't really seem like an argument one way or another. > I also find it disingenuous that you refer to the `<<Foo>>` syntax as > "the shift tokens" throughout, but do not similarly call your proposed > syntax "the double-suppression token". If one is "double-at", then the > other is "double-angle-brackets". I don't understand how it's disingenuous. The RFC refers to the shift tokens as such because that's what they are (`T_SL` and `T_SR`). The proposed `@@` syntax uses a new `T_ATTRIBUTE` token. > The one convincing *objective* argument I've seen is Jordi's, that > `@@` would be easily greppable. Interestingly, that's not true of > any of the other languages listed in the comparison other than Rust's > hash-bracket and maybe C++'s double-bracket, but that doesn't mean we > can't do better. Yes, I this is one reason I think having an `@@` token is a good fit for PHP, as preserving easy greppability has influenced other syntax decisions as well (e.g. the placement of return types). > Other than that, I think it really comes down to a matter of taste. Some > people reacted to the `<<Foo>>` syntax the way they did to the Cats movie > trailer, and may react to this one better. That's fine; we can make a > decision for subjective reasons, but let's be honest and say that. Well, I guess the line between objective and subjective may sometimes be a bit subjective. :) Best regards, Theodore

On Thu, June 4, 2020 at 3:28 PM Marcio Almada <marcio.web2@gmail.com> wrote: > I'd also prefer any attribute syntax without the bracket-like pair > of tokens. I'm just a bit confused about the RFC itself and the PR > content at this point. > > The RFC is currently proposing `@@MyAttribute()` and the PR > is currently implementing `@:MyAttribute()` as the sigil. The first > brings a BC break and the second doesn't, being the important > difference. > > I'm inclined to `@:` instead of `@@`. Which one will actually be > on the ballot? :D Hi Marcio, `@@` is the syntax that will be voted on. The linked PR is for the original `@:` implementation, but as the RFC notes switching this to `@@` just requires a single character to be changed in the lexer and a small grammar adjustment. If the proposal is accepted we'll submit a new PR with the updated implementation. Apologies for the confusion! Theodore

On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei <kontakt@beberlei.de> wrote:

Hi, The idea of making annotations forward compatible in php7 this way has a big + from me. I honestly don't mind the syntax too much. How would multiline notations work with this? #[ORM\Entity( arg1, arg2 )] This notation would obviously break in php7. Would it be possible (in this case) to do something like the following example? This would have php7 not care because they are comments, while php8 could filter the # out and make it a valid annotation. #[ORM\Entity( # arg1, # arg2 #)] I'm also okay with having everything on a single line, just wanted to point out this might cause issues. Regards, Lynn

+1 On Tue, Jun 9, 2020, 2:56 PM Benjamin Eberlei <kontakt@beberlei.de> wrote:

Am 09.06.2020 um 13:55 schrieb Benjamin Eberlei:

This would be great!

Hi Benjamin, On Tue, June 9, 2020 at 6:55 AM Benjamin Eberlei wrote: > Larry's suggestion about `#[Attr]` makes an important argument about > allowing to declare attributes in code in PHP 7 in a forward compatible > way that has not been brought up before. > > ```php > /** @ORM\Entity */ > #[ORM\Entity] > class User {} > ``` > > This code would work on PHP 7 and 8. That's an interesting argument. After thinking about it more, though, I'm not sure I understand what the benefit would be. The docblock annotation needed for PHP 7 is *already* forward compatible with PHP 8. So wouldn't this just be duplicating the attribute and opening the possibility for them to be out of sync for no benefit? Rather than duplicating attributes, wouldn't libraries simply stick with docblock annotations until they need to depend on other PHP 8 features anyway (e.g. union types), and then switch completely to the native attribute syntax? Furthermore, even if there was some benefit to having an attribute in both docblock and native syntaxes, it seems like this is a very short term concern. In a few years once libraries are depending on other PHP 8 features, will this even matter anymore? So I'm really not convinced that this forward compatibility argument should influence the syntax choice. > The `#[]` syntax would have about equally low breaking potential as `@@`. Is this really the case? There's no benefit to adding extra suppression operators, but I have seen code in the wild using hash comments starting with an opening bracket (e.g. to comment out an array, or for making checkboxes like `#[x] Some comment here`). > As such, instead of going through each alternative syntax one by one, > with with each having a 2/3 requirement to overthrow the old one, > I would be open to restart the secondary vote on Attributes syntax > with `<<>>` (status quo), `@@` and `#[]` using the same ranked voting > algorithm that was used for the PHP 8 RM vote. I'm certainly open to holding a three-way ranked choice vote like this, if others are okay with it. > I would take on the work to write about the third syntax alternative > then. The VoteRFC could just link to the three individual RFCs where > each discusses their syntax. I added a section to the Shorter Attribute Syntax RFC discussing the pros and cons of the `#[]` syntax. Let me know if you feel it isn't worded fairly. I think it would be preferable to have the syntax choices and voting options presented in one document rather than spread out in different places if possible. Best regards, Theodore

wt., 9 cze 2020 o 13:56 Benjamin Eberlei <kontakt@beberlei.de> napisał(a):

I just noticed a power of Rusts outer attributes which this syntax count follow in a future. Following outer attributes in Rust's we could introduce in a future syntax like <?php #![StrictTypes,Module("my_module"),Opcache(save_comments: true)] The last one used with recently proposed named arguments which could open a wide range of possibilities IMO. In Rust adding exclamation mark after hash `#!` imposes to take effect on the outer scope which inside a file would be the whole file. Going that path solution like that could possibly supersede `declare` statement in a future and allow to add compile-time attributes without breaking the language. I believe this is very important because any attribute which is not declared as a core and built-in is not taking an effect. This way it'd be possible to add new ones in future PHP versions. Even more with `zend_ast_process` it'd be possible to implement core attributes which take effect on whole file in extension. I can imagine this can possibly be discussed to allow attributes for eg. from ctor to take effect on class but am not 100% sure of it is useful. Going further with my imagination if we go that path with `#[Attribute]` we may think of adding error suppression. I know many don't like error-suppression but sometimes it's helpfull. In case of core attributes I can imagine a const value can be added renamed or removed, but the attribute remains the same then adding error suppression in a future allows to avoid crashing like for eg. #@[Jit(Jit::OPTIMISE_SOMETHING)] // where the const may exists or not, but the Jit attribute does function foo () {} In those cases we don't wanna crash the program, we may want it to continue rather without proper optimisation then not at all. I just see another use of current error-suppression operator @ to play nice with attributes. That's my 50 cents. Best regards, Michał Marcin Brzuchalski

Hi,

Hi! Thanks for the notification. I'll probably vote for the `@@` syntax for three reasons: - It feels similar with at least other 5 or 6 languages that choose `@` as their attribute sigil; - The lack of closing brackets make it less verbose, both on nesting and non nesting cases; - BC breaking the stacking of the error suppression operator as in `@@@@some_call()` actually makes some sense. AFAIK there was no reason to allow it, and maybe it was just an implementation oversight? So if the new proposal comes with this nice "fix" attached, at least it feels like a fix to me, it's two good changes on the same package. If not I'd propose to disallow `@@@...` combos myself separately if there is time to do so.

Thank you for your work. Cheers, Márcio

Hi Theodore, wt., 16 cze 2020 o 18:57 Theodore Brown <theodorejb@outlook.com> napisał(a):

Thanks for your work. I'm gonna take a vote on Rust syntax #[Attr] cause it's more than similar it's a copy of syntax which in Rust has other few extensions which we might consider in a future like for instance, a file scoped annotations. It has the benefit of reusing the same syntax as another language and allows the code works with both PHP 7 and PHP 8 which IMO is a huge benefit for a smooth migration. Cheers, Michał Marcin Brzuchalski