[Issue 13388] accept '@' before 'nothrow', 'pure', 'final', 'abstract' and 'override'

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #10 from Trey Brisbane <tbrisbane at 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.

--