FAQ for newbies who see pure @safe nothrow @nogc

[matovitch via Digitalmars-d]

On Thursday, 29 January 2015 at 16:13:59 UTC, Jonathan Marler 
wrote:
> On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
>> On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler 
>> wrote:
>>> On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
>>>> Yes, if @ttributes are better because you can create 
>>>> identifier with the same name why aren't they used 
>>>> everywhere ? By the way, the denomination makes sense too : 
>>>> function attibutes are either built-in or user defined 
>>>> attributes. But const can be a qualifier or a 
>>>> function/method attribute that is two very different 
>>>> things...maybe not beeing able to use const as a function 
>>>> attribute but @const would make more sense ?
>>>
>>> The purpose of this thread wasn't to re-discuss what was 
>>> already discussed.  The answer to your idea can be found in 
>>> the other thread 
>>> http://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org.
>>> It's gonna be a long read so I'll summarize what I believe is 
>>> the correct answer.
>>>
>>> The problem we are trying to solve is that the function 
>>> attributes are inconsistent.  Some use @ like "@safe" and 
>>> "@nogc" and some don't like "pure" and "nothrow".
>>>
>>> So one idea is to require an '@' symbol in front of all of 
>>> them for the sake of consistency.  The problem with this idea 
>>> is that you've now introduced inconsistency somewhere else.  
>>> Every keyword that you put an '@' symbol in front of, will be 
>>> used somewhere else without an '@' symbol.  Like this:
>>>
>>> abstract class MyClass { }
>>> @abstract void myfunc();
>>>
>>> See the inconsistency?  You're gonna end up with alot of 
>>> these types of inconsistencies. In addition, you've made the 
>>> rule of when to use the '@' symbol more complex.  Before it 
>>> was, "Use '@' if it is not a keyword".  Now it's, "Use '@' if 
>>> it is not a keyword except when it's a function attribute".  
>>> This definition will likely be made worse since people will 
>>> want to solve the newly introduced inconsistencies.  So the 
>>> new definition will become, "Use '@' if it is a keyword 
>>> except if it's a function attribute or a class specifier".  
>>> By the time you solve every inconsistency you'll have made 
>>> every usage of every keyword use the '@' symbol.  Then the 
>>> rule will be "Always use the '@' symbol".
>>>
>>> This will definitely be included on the FAQ :)  I'll reword 
>>> it and modify it but I agree that people will want an 
>>> explanation for this.
>>
>> One can argue that it's hard to remember what is a keyword 
>> (especially in D where there are many) and easier to 
>> distinguish beetween qualifiers and attributes. But I 
>> understand legacy code is an issue and I agree that the FAQ 
>> should just state the facts.
>
> This doesn't really have to do with Legacy code.  You can 
> always support both ways for a time and deprecate the old way.  
> It appears my answer did not address your idea well enough.  
> I'll have to put together a better explanation.  In the mean 
> time, could you help me by giving me the gritty details of your 
> idea.  I know others will also want an explanation for this so 
> I'd like to include one in the FAQ so as to prevent us from 
> explaining the same thing over and over.  You idea was to put 
> '@' on words if they are attributes and to omit them on 
> qualifiers.  Could you list what words are qualifiers and what 
> words are attributes?  I don't think this idea would work but 
> hey, maybe you'll prove me wrong, I'll admit I haven't gone 
> through the details of what problems this idea would create.

Sorry this may be my fault. I think there were only 4 qualifier 
in D : const, immutable, share and inout (I am not aware of this 
new "scope" thing). pure is a function attribute and a keyword, 
this is inconsistant with other built-in attributes with @ in 
front of them like @property or @nogc. I think (and my opinion 
doesn't worth much as I am not experienced as a programmer and I 
didnt used D very much) that it would be more consistant if we 
hadn't this keyword and be forced to use @pure instead. (const 
can be a method annotation/attribute too, so should be @const 
keeping const as a variable/parameter qualifier).