Don wrote: > > I genuinely thought @pure, @nothrow was a no-brainer. > > I really thought the explanation that "we made all attibutes use the @ > form, except those where it was prevented by historical precedent" was > quite defensible. > > But I was very, very wrong. Looks like the community is giving a massive > vote for complete unpredictability. > > <Throws hands in air />
Pick what you're going to pick. Personally, I have no problem with historical precedent. Changing public or private to be attributes would be quite disconcerting given how C++, Java, C#, D1, etc. all have them as keywords. And making them attributes would make porting code that much harder. It seems entirely valid to me. However, in the end, they are what they are and we just get to deal with it. Personally, I'd expect attributes to be more reflection-centric (as in potentially checked at runtime, though D's runtime reflection is currently lacking) and keywords to be more compile-time centric. I tend to think of attributes as being addons to the language rather than directly a part of it. So, either they're user-defined (which I don't think we can do in D yet), or they're the kind of thing which would result in giving compiler warnings, or allowing it to do some additional stuff, but aren't really a key part of the language. However, under that rational, I'd probably end up making most of the items currently up for discussion keywords rather than attributes. Regardless of why you choose to make a particular modifier an attribute or a keyword, there are going to be reasons to disagree. I don't think that it's quite as subjective as picking function names, but it's still pretty subjective. So, I don't think that worrying over the reasons for it is going to help much. Personally, I say pick the keywords such that it minimizes how much code will have to change - ported or otherwise. I think that historical reasons is a fine reason for choosing which way to go with a particular word. It's arbitrary enough already, so just minimize how much has to be changed. And when it comes down to it, we'll just have to deal with it however it is. If it's an attribute, we'll use it as an attribute. If it's a keyword, we'll use it as a keyword. In the end, I don't think that it matters all that much when it comes to new code. But at least historical reasons would limit the amount of code that would have to be changed. - Jonathan M Davis