[JSR308] Postfix syntax for type annotations

Neal Gafter gafter at google.com
Sun Feb 25 10:04:48 EST 2007


On 2/25/07, Michael Ernst <mernst at csail.mit.edu> wrote:
>
> I am reopening the discussion of the postfix syntax for type annotations.
>
> I presume that everyone has already read the discussion on the JSR 308
> webpage, which used to appear in "resolved issues" but which I have moved
> back into "open issues".  It would not be productive to make comments
> without first reading that.  I have also appended it below my signature,
> for reference.
>
>                     -Mike
>
>
> [The following text is from http://pag.csail.mit.edu/jsr308/.]
>
>
> Postfix syntax for type annotations
>
> The current proposal uses a simple prefix syntax for type annotations: the
> annotation appears before the type, as in @NonNull String. There are two
> exceptions to this general rule: the syntax for arrays (which is still up
> for debate) and the syntax for method receivers.
>
> An alternative would use a simple postfix syntax for type annotations:
> type
> annotations would appear after the type, as in String @NonNull. This
> syntactically separates type annotations from all other annotations,
> putting them in a different place in the syntax. In
>
>         @A Type @B var;
>
> @A would refer to the variable and @B would refer to the type.
>
> Advantages: This reduces the number of special cases in the syntax by one
> (no special case is needed for arrays), which may be less confusing to
> programmers.


Actually, it removes many more special cases.  It removes the ambiguity on
method return types and variable types, and it supports all the other
contexts that I listed recently that aren't even supported by the current
proposal.

Disadvantages: Programmers must remember which annotations are type
> annotations and which are not, which may be confusing. The postfix syntax
> introduces more new locations in a program where annotations may be placed
> (the prefix syntax reuses existing locations for variable declarations
> without ambiguity); in this sense, it feels like a bigger change to
> Java.


Programmers don't have to remember anything! Rather programmers have to
decide when they're writing an annotation, for example in a method
declaration, whether they're intending to annotate the return type or the
method itself, and record that decision unambiguously in the source code.
Presumably the programmer knows what she is trying to express, and
"remembering" which kind of thing a particular annotation type is - well,
that is the least of her problems.  The reader of the program is more
important than the programmer, and a syntax that doesn't have this ambiguity
will make programs easier to read.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070225/8d05593d/attachment.htm


More information about the JSR308 mailing list