https://issues.dlang.org/show_bug.cgi?id=13388
--- Comment #10 from Trey Brisbane <tbrisb...@gmail.com> --- I think this should be looked at in terms of conceptual differences between the attributes using keyword notation, vs. those using @-prefix notation, as well as compliance to C compatibility. For instance, why are static, const, immutable, final, shared, __gshared, and deprecated, keywords, while @property, @safe, @trusted, @system, @disable, and @nogc, are UDAs? What is the underlying conceptual difference here that necessitates the separation? I'm not sure anyone really knows, and that's why we have this problem in the first place. I think we can safely say that const, static, public, protected, private, etc are keywords to conform to C/C++ code-style, but what about the rest? The following is what I'd do given the option, and what would be (IMO) a great system to adopt in the language, but this is just my opinion and I'm sure others would disagree: Keywords: extern, align, package, private, protected, public, export, pragma, static, extern, abstract, final, synchronized, auto (shouldn't this be a type?), scope, const (shouldn't this be part of the type?), immutable (shouldn't this be part of the type?), inout, shared, __gshared, property, and ref (shouldn't this be part of the type?). UDAs: deprecated, override, nothrow, pure, safe, trusted, system, disable, nogc. In terms of a general solution, I see it as though we have 4 options: 1) Resolve the inconsistency through community engagement and voting (ala. democracy) 2) Resolve the inconsistency by going all or nothing in either direction (i.e. all UDAs or all keywords) 3) Define the requirements/rational for attributes to exist in one category vs. the other, so that developers have a conceptual grounding when trying to rationalize the difference 4) Allow either notation for either some or even all of the attributes, documenting the idiomatic way, and let the developers ultimately decide Given that there seems to be a detrimentally-large resistance to breaking changes in the language (which is a little concerning in itself), I see option 4 as the only reasonable way forward. @Jonathan: I understand your angle with regard to user confusion, but given the alternatives are either never ever fixing this, or breaking changes, are you sure you'd rather go down the route of never fixing this? User confusion can be addressed by making appropriate documentation for this change. I.e. State in the documentation that the idiomatic way is to use @-style notation, but that not including it also works for legacy reasons. Done. Old code doesn't break, and new users will have to read the documentation anyway. @bearophile: On only doing things one true way, see here why this argument makese no sense: http://dlang.org/pragma.html#Pragma On not adding anything useful to D, I disagree. Fixing this issue in some way or another adds consistency and elegance to the language. When I show people D code, almost invariably people say things along the lines of "Why does property require the @-symbol, where as nothrow doesn't?", followed immediately by "Eww, well that just looks ugly.". In my experience, it's a build-up of little dirty bits here and there that wards off adoption of a new language with most people, because it means they're forced to *look at* the problems with the language, and often can't get past that even when shown the best features of said language. D should strive to fix things like this, because if the syntax is absolutely clean and elegant, then at least people won't have to *look at* problems in the language. --