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.
