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

[Alex Buckley]

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
>>
>
>
>