On 10/17/16 10:12 AM, timepp wrote:
there is "@disable", using @ as prefix;
there is "__gshared", using __ as prefix;
there is also "align", not using prefix.
I failed to summarize a rule here. Can anyone tell the underlined
terms without adornments are keywords. They are used in parsing to
anchor the parser, and can only mean what they are intended to mean by
the language. This means they are reserved by the language, and can't be
used by users of the language.
Terms with __ are also keywords, but are marked that way because they
are used in unusual circumstances, were intended to be replaced with a
more formal keyword, or were chosen as not to interfere with any
existing symbols (i.e. added after much D code already existed). The
language tries not to add keywords any more because it breaks any code
that uses it. There aren't many of these. In general, you should not use
symbols with two underscores because those are expected to be reserved
by the language or compiler. It's not a hard-fast rule, but I'd expect
there to never be any new keywords that don't start with __.
The terms with the @ sign are attributes, and can only be used as
attributes. They are never storage classes, types, or keywords in
general. In this space, the language has many pre-defined attributes,
and you can't use them to mean something different (as attributes) once
the language has defined it. Think of these as pre-defined symbols. The
nice thing about these are that you can use them as regular symbols
without the @ sign, and it doesn't change anything. As long as you don't
intend to use them as actual attributes, you should be fine. However,
I'd recommend not to do this as this can be confusing to anyone reading
your code and not knowing the pre-defined attributes.
Note that attributes were added much later in the language, and most of
the predefined attributes were added before user defined attributes were
supported. So I expect not many more language defined attributes will be
added unless absolutely necessary.
You may ask, why the difference between e.g. @safe and pure? Historical
reasons really. It should really be @pure, but pure was a keyword from
very early. So there is a bit of that.