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.


Reply via email to