Should pure nothrow ---> @pure @nothrow ?

[Denis Koroskin]

On Fri, 27 Nov 2009 12:30:30 +0300, Lars T. Kyllingstad  
<public at kyllingen.nospamnet> wrote:

> Denis Koroskin wrote:
>> On Fri, 27 Nov 2009 12:09:05 +0300, Don <nospam at nospam.com> wrote:
>>
>>> #ponce wrote:
>>>>> Definitely. And what about @deprecated and @override?
>>>>  As override is now required, i don't think it should be an attribute.
>>>
>>> As I understand it, one of the characteristics of attributes is that  
>>> you should be able to remove them from the entire program, without  
>>> affecting the behaviour.  All they are doing is adding additional  
>>> compile-time constraints. (const and immutable aren't attributes,  
>>> because you're allowed to overload functions based on them).
>>>
>>> So @deprecated is definitely an attribute.
>>>
>>> Is override really required? I've just tested on DMD2.037, and it  
>>> still accepts functions without it. So at present it is behaving like  
>>> an attribute. But if it became mandatory, I'm not so sure.
>>  override is required when compiling with -w.
>>  By Walter's definition, @property is not a valid attribute, because by  
>> removing it the program will fail to compile (due to missing parens in  
>> accessors). Either that or omissible empty parens will still be  
>> present, but I see no usefulness of @property in that case.
>
> But it still doesn't affect the generated binary code, and I think  
> that's the important part here.
>
>     @property void foo(int i) { ... }
>     foo = 7;
>
> generates the exact same code as
>
>     void foo(int i) { ... }
>     foo(7);
>
> We need a definition of attributes/annotations that is a bit wider than  
> "can be removed from program without anything happening". Denis' example  
> clearly demonstrates this.
>
> Something in the vein of "annotations only provide additional  
> information and constraints for the compiler, and do not affect the  
> generated code" would be better.
>
> -Lars

I think "do not affect the generated code" is a bit restricting. I see  
attributes as hints to compiler (especially since there is no way to use  
user-defined attributes). Compiler may understand and make use of some of  
them. For example, I'd like to be able to annotate a function as  
@thread-safe, and hope that a smart compiler will optimize my code based  
on that information (it doesn't mean it have to). Other example is that  
I'd like for some functions to leave all bounds checks (even in -release)  
without making it @safe. Or profile this concrete method. Or exclude this  
concrete method from profiling. There are endless possibilities.

Some of this attributes might be vendor-specific, they should probably  
start with a double-underscore (e.g. @__naked).

That's the way I see attributes.