Why do some language-defined attributes have @ and some not?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, 23 October 2014 at 22:20:28 UTC, ketmar via 
Digitalmars-d-learn wrote:
> i love D and i want D to be widespread, but what makes me love 
> D is
> it's attitude to fixing stupid legacy we have in C and C++. and 
> now it
> seems to me that someone should start "BetterD" project to fix 
> legacy
> we already have in D. ain't the desire to fix legacy cruft was 
> one of
> the big driving forces of D creation? it's a pity for me to see 
> that D
> starting to follow some of the worst C++ aspects.

_Every_ language ends up with legacy cruft if it ever gets any 
kind of widespread use in the real world. If you want a language 
that never has legacy cruft, I expect that you will be forever 
disappointed. The question is what is and is worth changing and 
at whether you ever reach the point that you're _never_ allowed 
to break code (which is pretty much where C++ is). I certainly 
hope that D never reaches the point that we'll never break code 
even when it truly makes sense to do so, but we _have_ reached 
the point where the reasons have to be much stronger.

Some stuff that could currently be considered legacy cruft will 
probably be changed, but it's generally a hard sell, particularly 
because Walter is _very_ paranoid about breaking people's code 
(arguably too much so). Though it should be noted that the vast 
majority of D users never post in the newsgroup, and many of them 
probably have never visited it, so basing anything on what's 
discussed in the newsgroup is basing it on the most dedicated 
users, which aren't necessarily representative of the user base 
sa a whole, which always makes it difficult to figure out which 
decisions that would break code are okay and which aren't and is 
probably part of why Walter overreacts to some of the comments on 
places like reddit.

Regardless, you can certainly try and lobby for the attribute 
names to be normalized, but I don't expect it to change, in this 
particular case, while I'd certainly be open to it if Walter want 
to get rid of all of the @s on all of the built-in attribute 
names, I also don't really care if they stay the way they are. 
It's a minor annoyance, but I never found it hard to learn which 
ones had @ on them and which didn't (just treat it like one extra 
letter to learn in the keyword), and I'm light years beyond the 
point where I memorized them all. The primary annoyance about it 
at this point is having to answer questions on it when yet 
another user tries to figure out why some have @ and some don't 
as if there's a discernable pattern to it, and there isn't. And 
that sucks, but it doesn't actually cause bugs (unlike allowing 
const on the left-hand side of a member function, which 
definitely should be deprecated), and it's actually pretty easy 
to explain.

- Jonathan M Davis