Source code annotations alla Java

Jacob Carlborg doob at
Thu Jan 20 12:48:37 PST 2011

On 2011-01-20 21:34, Steven Schveighoffer wrote:
> On Thu, 20 Jan 2011 15:03:55 -0500, Jacob Carlborg <doob at> wrote:
>> On 2011-01-20 19:18, Steven Schveighoffer wrote:
>>> On Thu, 20 Jan 2011 13:07:58 -0500, Jacob Carlborg <doob at> wrote:
>>>> On 2011-01-20 15:02, Steven Schveighoffer wrote:
>>>>> On Thu, 20 Jan 2011 08:47:28 -0500, Justin Johansson <jj at>
>>>>> wrote:
>>>>>> Not long ago the Java Language people introduced the idea of
>>>>>> annotations together with an annotation processing tool (apt).
>>>>>> Now perhaps the idea of source code annotations is not actually a
>>>>>> Java
>>>>>> invention per se, however for someone learning D is there any
>>>>>> equivalent idiom [of Java annotations] in the D language?
>>>>> Haven't used Java since they added annotations, but I think they are
>>>>> like C# attributes?
>>>>> In any case, D has an annotation syntax like:
>>>>> @property
>>>>> But I think at the moment, annotations have no custom ability. Only
>>>>> compiler-defined annotations are allowed. This may change in the
>>>>> future,
>>>>> but probably not short-term. FWIW, I think we need a much richer
>>>>> runtime-reflection capability before we can use custom annotations to
>>>>> any great effect.
>>>>> -Steve
>>>> I would rather formulate it like: currently D has a syntax for
>>>> keywords that are similar to Java annotations.
>>> I don't think it's the same thing. Keywords are not allowed to be used
>>> anywhere else, even for things that would parse properly were they not
>>> keywords. They are anchors for the parser to determine where it is. In
>>> contrast, a compiler-defined annotation is parsed just the same as a
>>> custom one, it's just that the meaning is predefined.
>>> For example, you can legally do:
>>> int property;
>>> without error, but this won't even get past the parsing stage:
>>> int struct;
>>> -Steve
>> I assume you meant "int @property;"?
> No. I meant int property;

Of course that would work, isn't that like saying this won't work:

int struct_; // ?

> A keyword is specifically not allowed where the grammar would otherwise
> allow it. A symbol isn't allowed to have @ in it, so this naturally
> prevents a conflict. I realize the poor example, but it's definitely not
> a keyword. Otherwise, it would be listed here:
> (actually, are
> annotations part of the lexical grammar there?).
> It's more like Object, which is not a keyword, but you aren't allowed to
> use it to mean anything besides what it means.
> The end result is, it fails if you use it in the wrong place, but the
> keyword status makes it fail at the parsing stage. I am not a compiler
> writer, so I'm talking a bit from my ass here.
> -Steve

Ok, maybe you're right. I'm pretty sure, as you say, that a keyword in 
the wrong place would fail during parsing. But I don't know where a 
misplaced annotation/attribute would fail.

/Jacob Carlborg

More information about the Digitalmars-d-learn mailing list