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

[Markus Keller]

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