January 27, 2015
When I read discusion about @nothrow @pure... I start thinking what will happen if  go that way.

If we make an agreement on @pure and so on we are ok now because pure is a keyword already. But if there will be that consensus all other attributes should have @ in name. For eg. we add @virtual or @forceinline. This could cause some code breakage if someone already use UDA with this name.

One way how to avoid it would be allow @pure @virtual and others only on right side so it would not clash with UDAs so this code will work:

struct virtual {}

class C
{
    @virtual void someFun() @virtual {}
}

But it does not look OK for me.

So I think it would be nice to have some name convention for UDAs, so one can be sure it will never be in conflict with compiler attributes.

So what do you think?
January 27, 2015
On Tuesday, 27 January 2015 at 23:02:33 UTC, Daniel Kozak wrote:
> When I read discusion about @nothrow @pure... I start thinking what will happen if  go that way.
>
> If we make an agreement on @pure and so on we are ok now because pure is a keyword already. But if there will be that consensus all other attributes should have @ in name. For eg. we add @virtual or @forceinline. This could cause some code breakage if someone already use UDA with this name.
>
> One way how to avoid it would be allow @pure @virtual and others only on right side so it would not clash with UDAs so this code will work:
>
> struct virtual {}
>
> class C
> {
>     @virtual void someFun() @virtual {}
> }
>
> But it does not look OK for me.
>
> So I think it would be nice to have some name convention for UDAs, so one can be sure it will never be in conflict with compiler attributes.
>
> So what do you think?

I agree that putting language defined attributes on the right hand side would be a good thing.  It makes things consistent.  Also, if we did that then we could enhance the grammar to support removing the '@' symbol on these attributes without making them keywords and without making the grammar ambiguous.  Plus, it's easier to parse that way.  Better for syntax highlighting.