[type-annos-observers] ordering of annotated array brackets

[Alex Buckley]

The JLS sections I mentioned describe how to form the array type of a 
declared entity (variable, method return type) by reading bracket pairs 
if present. Regardless of type annotations, those sections should be 
updated to point to 10.2 to get a centralized definition of how to read 
an array type [you alluded to that definition before]. With regard to 
type annotations that thread themselves into an array type, my concern 
is to keep the centralized definition as simple as possible - "one pass, 
left to right".

I understand the a2[0]=a1 scenario. Since making it well-typed means 
redefining the array type construction rule to consider post-identifier 
[] first, I am happy for a2[0]=a1 to not be well typed. There is a 
simple fix here: declare a1 and a2 in different declarations.

Alex

On 3/18/2014 8:42 AM, Markus Keller wrote:
> Nobody wants to touch all the JLS sections you mentioned. The grammar is
> fine, and all those sections don't say a word about array types (let alone
> about type annotations on array types).
>
>> The driver for your interpretation of annotated mixed array syntax seems
>
>> to be a desire to write multiple declarators in a single declaration.
>
> Yes, because the multi-declarator syntax is THE reason why the
> post-identifier brackets notation exists and is used at all. [1]
>
> Do you disagree with all the examples that were given?
>
>>> @A Elem @B [] a1, a2 @C [];
>>>
>>> should allow:
>>>
>>>     a2[0] = a1;
>
> By the simplistic "one pass, left to right" rule, this assignment would
> not be well-typed. Why would that be favorable?
>
> The mixed array type notation is already discouraged, so the more involved
> annotation order is not a big deal in practice. Consistency of the
> language is more important than a "simpler" interpretation that would
> invalidate existing code when type annotations are added.
>
> [1] The Java Tutorial already discourages the post-identifier brackets
> notation:
> http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html
> The JLS could do the same.
>
> Markus
>
>
> Alex Buckley <alex.buckley at oracle.com> wrote on 2014-03-17 23:53:44:
>> Hi Werner,
>>
>> Mixed array syntax is germane to the type of a declaration (variable /
>> method) in the following JLS sections: 8.3, 8.4, 9.3, 9.4, 9.6.1, 14.4,
>> 14.14.2, and 15.27.1.
>>
>> Those are important sections. Having them define the type in a way that
>> leads with post-identifier syntax is a non-starter for me. (This applies
>
>> whether each section defines the type itself, or points to a central
>> definition in 10.2 when square brackets are involved.)
>>
>> The driver for your interpretation of annotated mixed array syntax seems
>
>> to be a desire to write multiple declarators in a single declaration. I
>> suggest it is more readable to write one declarator per declaration (the
>
>> "let's separate a1 and a2" case), and keep the rules for array types
>> simple: one pass, left to right.
>>
>> Alex
>>
>> On 3/17/2014 9:56 AM, Werner Dietl wrote:
>>> Alex, all,
>>>
>>> I found the arguments by Mike and Markus convincing.
>>> I previously only looked at the purely optical impression of moving an
>>> identifier between different pre-/post-identifier array brackets.
>>> However, thinking about the operations performed on them seems more
> important.
>>> I particularly like Markus' example of converting between arrays and
>>> List. To expand on that:
>>>
>>> @A Elem @B [] a1, a2 @C [];
>>>
>>> should allow:
>>>
>>>     a2[0] = a1;
>>>
>>> Similarly, using List, we would have:
>>>
>>> @B List<@A Elem> a1, a2 @C [];
>>>
>>> which still allows "a2[0] = a1;".
>>> Now let's separate a1 and a2:
>>>
>>> @B List<@A Elem> a1;
>>> @B List<@A Elem> @C [] a2;
>>>
>>> and now go back to all arrays:
>>>
>>> @A Elem @B [] a1;
>>> @A Elem @C [] @B [] a2;
>>>
>>> The component type of a2 is "@A Elem @B []" which again allows the
> assignment.
>>>
>>> I find thinking about the array / List correspondence helpful and now
>>> agree with Markus and Mike that the current javac/ecj behavior is
>>> desired.
>>>
>>> cu, WMD.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 6, 2014 at 11:57 AM, Markus Keller
> <markus_keller at ch.ibm.com> wrote:
>>>> Alex Buckley <alex.buckley at oracle.com> wrote on 2014-03-05 20:34:20:
>>>>> Post-identifier brackets are a corner case, and mixed array syntax
> is a
>>>>> corner case of that corner case. It's unreasonable to bend a core
> part
>>>>> of the language - i.e. the rules for "declared type of a field /
> local
>>>>> var / formal parameter" - to support a corner case of a corner case.
>>>>
>>>> I'm sure we can find a better wording for the paragraph in 10.2, so
> that
>>>> we don't have to sacrifice the internal consistency of the array type
>>>> notations. And the new wording can even add the missing definition of
> the
>>>> array brackets order for non-mixed array types. Type annotations are
> part
>>>> of the language now, so they need to be specified. The rules for the
> core
>>>> part of the language don't have to be changed much.
>>>>
>>>> Proposal:
>>>>
>>>> * Add to 10.1:
>>>> -----
>>>> The leftmost bracket pair of an array type stands for the outermost
> array
>>>> dimension; a following bracket pair for the array's component type,
> and so
>>>> on. Each bracket pair can be annotated with type annotations
> (§9.7.4).
>>>>
>>>>           <informal>
>>>>           For example, given the field declaration:
>>>>
>>>>                   @C int @A [] @B [] f;
>>>>
>>>>           @A applies to the array type int[][], @B applies to its
> component
>>>> type int[], and @C applies to the element type int.
>>>>           </informal>
>>>> -----
>>>>
>>>> * Change 10.2:
>>>> -----
>>>> [..] the array type of a variable is denoted by the array type that
>>>> appears at the beginning of the declaration, extended by any bracket
> pairs
>>>> that follow the variable's Identifier in the declarator.
>>>>
>>>> If present, the first bracket pair that follows the variable's
> identifier
>>>> stands for the outermost array dimension; a following bracket pair
> for the
>>>> array's component type, and so on. The component type of the last
> array
>>>> dimension is the type that appears at the beginning of the
> declaration
>>>> (and that type can be an array type itself).
>>>> -----
>>>>
>>>> The last example in 10.2 could get a clarifying type annotation:
>>>>
>>>>           float[][] f[][], g[][][], h @A []; // Yechh!
>>>> ...
>>>>           float @A [][][] h;
>>>>
>>>>
>>>> Markus
>>>>
>>>
>>>
>>>
>>
>