accept @pure @nothrow @return attributes

[Jonathan M Davis via Digitalmars-d]

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