[JSR308] Others possible syntaxes for type annotations

[Maxim Kizub]

For me the specification List<@Readonly T> looks like @Readonly is the 
annotation of T.
Nevertheless, it's also an option to vote, and others people may prefer 
your variation more.
The main idea in my case is to make the syntax like C++ templates, which 
allow not only types, but values as well.
Annotations separated by comma in the type argument list looks like 
additional parameters of the type.
Alternative semicolon separator has to clearly separate annotations from 
types.
In your case (with leading annotations) I would insert a separator 
(comma or semicolon) before the types, like

Hashtable<@Readonly @Threadsafe; A, B> or Hashtable<@Readonly 
@Threadsafe, A, B>

Eugene Kuleshov wrote:
>
>  Interesting. It seems like there is no ambiguity, but such syntax 
> look confusing. Mostly because of "," or ";" used to separate 
> annotations. But the idea is still worth investigation.
>
>  I've tried to play with the following grammar change and like it more 
> when type annotations are put before type arguments or parameters. 
> There is still no ambiguity and optional annotations are reasonably 
> separate from other type arguments. The only concern here is that such 
> syntax is more verbose then syntax proposed by the currently 
> implemented prototype.
>
> TypeArguments:
>        <[Annotations] TypeArgument {, TypeArgument} >
> TypeParameters:
>        <[Annotations] TypeParameter {, TypeParameter} >
>
>  Here is how examples from JSR-308 document would look in such syntax:
>
>    Map<String<@NonNull>, List<@NonEmpty Document<@Readonly>>> files;
>
>    o.<String<@NonNull>>m("...");
>
>    class Folder<F extends File<@Existing>> { ... }
>    Collection<? super File<@Existing>>
>
>    class UnmodifiableList<T> implements List<@Readonly T<@Readonly>> { 
> ... }
>
>    void monitorTemperature() throws TemperatureException<@Critical> { 
> ... }
>
>    myString = (String<@NonNull>) myObject;
>
>    boolean isNonNull = myString instanceof String<@NonNull>;
>
>    new List<@NonEmpty @Readonly String>(myNonEmptyStringSet)
>
>    new <@Interned String> MyObject()
>
>    public <@Readonly> int size() { ... }  // method receiver
>
>    Class<String<@NonNull>> c = String<@NonNull>.class;
>
>  regards,
>  Eugene
>
>
> Maxim Kizub wrote:
>> I think, grammar changes may be specified as:
>>
>> TypeArguments:
>>       < TypeOrAnnotArgument {, TypeOrAnnotArgument} >
>>
>> TypeOrAnnotArgument :
>>       [TypeArgument | Annotation]
>>
>> or as
>>
>> TypeArguments:
>>       < ? [TypeArgument {, TypeArgument}] ?[; Annotations] >
>>
>> I'm not familiar with this parser grammar notation, so I don't know 
>> how to express that annotations go after type parameters.
>> For JavaCC grammar would be:
>>
>> TypeArguments() : {}
>> {
>> "<"
>>   TypeArgument() ( "," TypeArgument())* ( "," Annotation() )*
>> |   Annotation() ( "," Annotation() )*
>> ">"
>> }
>>
>> or
>>
>> TypeArguments() : {}
>> {
>> "<"
>>   TypeArgument() ( "," TypeArgument())* [ ";" Annotations() ]
>> |   [ ";" ] Annotations()
>> ">"
>> }
>>
>> JavaCC grammar needs no lookahead, since annotations are clearly 
>> distinct from type parameters (because they start with @ token)
>>
>> Map<Foo<Boo>, Map<String, Boo>> can be annotated as
>>
>> Map<Foo<Boo, @BooAnnot>, Map<String, Boo, @MapInnerAnnot>, @MapAnnot>
>>
>> or using semicolon as the separator
>>
>> Map<Foo<Boo; @FooAnnot>, Map<String, Boo; @MapInnerAnnot>; @MapAnnot>
>>
>> or annotating everything will be
>>
>> Map<Foo<Boo<@BooAnnot>; @FooBooAnnot>, Map<String<@StringAnnot>, 
>> Boo<@BooAnnot>; @MapStrBooAnnot>; @MapFooBooMapStrBooAnnot>
>>
>
>
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>