[type-annos-observers] type annotations on generic method return type

[Werner Dietl]

What would be bad about this:

MethodHeader:
  {MethodModifier} Result MethodDeclarator [Throws]
  {MethodModifier} TypeParameters {Annotation} Result MethodDeclarator [Throws]

If you don't like the "Result MethodDeclarator [Throws]" duplication,
you could introduce a MethodHeaderRest for it.

But maybe I misunderstand what ambiguity you mean.

cu, WMD.


On Thu, Feb 6, 2014 at 7:01 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> No, I meant "reject the @B". If you want it to be accepted, please provide
> an unambiguous JLS grammar for MethodHeader.
>
> Alex
>
>
> On 2/6/2014 3:59 PM, Werner Dietl wrote:
>>
>> Alex,
>>
>> In your last sentence:
>>
>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>> reject the @B after the type parameter section.
>>
>>
>> don't you mean "accept the @B"?
>> It would be quite ugly if we had to separate a type annotation on the
>> return type by the type parameter section.
>>
>> cu, WMD.
>>
>>
>> On 02/06/2014 06:43 PM, Alex Buckley wrote:
>>>
>>> First of two mails. Not good news in this one.
>>>
>>> On 2/6/2014 8:58 AM, Markus Keller wrote:
>>>>
>>>> What about a generic method declaration, where a type parameter
>>>> declaration "<T>" separates the method modifiers from the return type's
>>>> type annotations?
>>>>
>>>>       public @A <T> @B Set<T> foo(T t) { /*...*/ }
>>>>
>>>> => @B is _not_ syntactically legal according to the current grammar,
>>>> since
>>>> Result cannot start with an annotation:
>>>>
>>>> MethodHeader:
>>>>           {MethodModifier} [TypeParameters] Result MethodDeclarator
>>>> [Throws]
>>>>
>>>> Result:
>>>>           UnannType
>>>>           void
>>>>
>>>> Both javac and ecj currently accept the above declaration.
>>>
>>>
>>> The original 308 spec (java-annotation-design.pdf) didn't address
>>> generic method declarations. Here are the relevant productions from JLS7
>>> ch.18:
>>>
>>> ClassBodyDeclaration:
>>>    ...
>>>    {Modifier} MemberDecl
>>>
>>> MemberDecl:
>>>    GenericMethodOrConstructorDecl  // Not modified by 308
>>>    MethodOrFieldDecl               // Modified by 308
>>>    ...
>>>
>>> // Modified by 308
>>> MethodOrFieldDecl:
>>>    UnannType Identifier MethodOrFieldRest
>>>
>>> // Not modified by 308
>>> GenericMethodOrConstructorDecl:
>>>    TypeParameters GenericMethodOrConstructorRest
>>>
>>> GenericMethodOrConstructorRest:
>>>    (Type | void) Identifier MethodDeclaratorRest
>>>    ...
>>>
>>> Type:
>>>    [Annotations] UnannType
>>>
>>> The effect was to allow @B after the type parameter section:
>>>
>>>    public <T> @B Set<T> foo(...) {...}
>>>
>>> and of course @A as a modifier before the type parameter section:
>>>
>>>    public @A <T> Set<T> foo(...) {...}
>>>
>>> Ordinarily, I would change JLS8 to agree with that intent (albeit rather
>>> subtle) and with the behavior of both compilers. That is, I would regard
>>> this whole topic as a minor spec integration problem.
>>>
>>> Unfortunately, JLS8 cannot be cleanly changed. The problem is the ch.8
>>> grammar for MethodHeader, distinct from the old ch.18 grammar. We cannot
>>> change MethodHeader to:
>>>
>>> MethodHeader:
>>>    {MethodModifier} [TypeParameters] {Annotation} Result ...
>>>
>>> because, without no type parameters present, any annotations immediately
>>> to the left of Result would be ambiguous.
>>>
>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>> reject the @B after the type parameter section.
>>>
>>> Alex



-- 
http://www.google.com/profiles/wdietl