accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Tuesday, 27 January 2015 at 16:50:00 UTC, Jonathan M Davis 
wrote:
> On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via 
> Digitalmars-d wrote:
>> On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
>> > You're right. I forgot about those two. But it's still the 
>> > case that the
>> > number of function attributes that don't have @ on them 
>> > is_far_  greater
>> > than the number of those that do.
>>
>> But I explained that most function attributes don't only apply 
>> to
>> functions but to variables as well:
>>
>> public, protected, package, private, static, const,
>> immutable, inout, and deprecated
>>
>> So it can be consistent that the above don't use @.
>>
>> These only affect functions, not variables, so should be 
>> @attributes IMO:
>>
>> final, override, abstract
>>
>> These affect both:
>>
>> return, ref
>>
>> So if we want some kind of consistency, we can achieve it by 
>> adding @
>> for final, override, abstract, and removing it for 'return'.
>
> abstract also applies to classes, as does final. Also, if we 
> end up adding
> any new attributes later, they're bound to have @ on them to 
> avoid requiring
> a keyword (which is why we have @ on some of them in the first 
> place), and
> if the new attribute applies to variables or types as well, 
> then the
> division that you're suggesting falls apart.
>
> IMHO, if we have to search for a way to make them consistent, 
> then there's
> no point. We're just going to end up with making things more 
> consistent in
> one way and less in another without necessarily making it any 
> easier for
> anyone to keep track of, so we'd just be shuffling things 
> around. I think
> that there needs to be a clear and solid benefit to changing 
> which
> attributes have @ and which don't, or we shouldn't mess with 
> them.
>
> Honestly, I just consider @ to be part of the name, and I 
> memorized it as
> part of the keyword. The result is that I don't even remember 
> ever having a
> problem trying to figure out which attributes had @ and which 
> didn't. Sure,
> it would be nice we had a rule of thumb that we could give 
> newbies that
> would tell them which to use, but so few have @ that I really 
> don't think
> that it's much of a practical issue - just an aesthetic one.
>
> I'd also point out that the compiler will give an error message 
> telling you
> which attributes have @ on them you use something like 
> @deprecated, so it's
> not hard at all to figure out what you did wrong. So, even if 
> someone has
> trouble remembering which built-in attributes start with @, 
> they'll figure
> out where they got it wrong quite quickly.
>
> - Jonathan M Davis

I share your sentiments exactly.  The only thing I would add is 
that I don't see why we can't just remove the '@' symbol from all 
language defined function attributes.  I've already proposed a 
way to do this that wouldn't add any more keywords and would be 
fairly trivial to do (see my previous posts).  However, since 
Walter doesn't like my idea I guess it's dead.  However, I can't 
figure out why he doesn't like it...so.

This issue isn't a huge deal, like you said it's not too hard to 
learn which ones require the '@' symbol and which ones don't, it 
just looks weird.  It's just too bad that my solution isn't even 
considered even though it would solve all these issues.