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

[Werner Dietl]

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
>



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