indexed access: 10 ways to fix 'harmfull' issue

[Artur Biesiadowski]

Ruslan Shevchenko wrote:
> 3. Change semantics in assigment in that way, that indexed assigment also
> return value of right part, casted
>  to type of left part.
>  looks strange from some point of view : minor:
> // (x[i]=b)==x[i]  can be not always true, becouse we return right part
> instead left.
>
> Map<Integer,Integer> x = new HashMap<Integer,Integer>();
> if ((x[1]=128)==x[1]) {
>  System.err.println("eq");
> } else {
>  System.err.println("neq");
> }
>  will print neq.
>
> int[] x = new int[1];
> if ((x[1]=128)==x[1]) {
>  System.err.println("eq");
> } else {
>  System.err.println("neq");
> }
>  will print eq.
>
>  backward compability: yes (if will not change rules for arrays and
> variables)
>  extra  overhead:      no
>  limited functionality: no
>
> //Comment: some existing statements of JLS will be changed, but for arrays
> and plain variables
> // we have choise:  left the same as previous,
>   

As far as I understand it, your upper example will also return eq. 128 
will be autoboxed to Integer, then duplicated on stack, then put into 
x[1] and then compared to value got from x[1]. Additionally, don't use 
x[1] on array of length 1 ;)

I think that better example to show the confusion is

Integer x,z
int y;
z = 1000;
x = (y = z);

then x != z

Which is the case currently. Same way for possible map syntax.

Map<Integer,Integer> map;
int y;
map[1] = 1000;
map[0] = (y = map[1]);

then map[0] != map[1]


While it is maybe not the most obvious behaviour, it is exactly the same 
thing as we observe today (see Integer example above). As far as I 
understand, it is specified exactly this way in JLS, so this option 
actually means "don't change anything in JLS".

Same example as above can be also applied for Integer[] array.
Integer[] x = new Integer[1];
System.out.println(x[0] == (x[0]=1000));
is false currently.


Regards,
Artur Biesiadowski