FAQ for newbies who see pure @safe nothrow @nogc

Jonathan Marler via Digitalmars-d digitalmars-d at puremagic.com
Thu Jan 29 08:13:58 PST 2015


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.


More information about the Digitalmars-d mailing list