www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UDAs name convention

reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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?
Jan 27 2015
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
Jan 27 2015