A simple solution for [] access that can trivially be added to List and Map.

[Reinier Zwitserloot]

Ulf: yes, my interface names sucked. Yours are better, though I  
believe the more accepted spelling is two T's (PuttableByKey, not  
PutableByKey).

Peter: Replies inline

On 2009/25/06, at 23:55, Peter Levart wrote:
> Considering your extension of rule 8.4.8.3 this is not always the  
> case. Anything can be returned. It depends on the static type of the  
> receiver and what that type defines as a set/put method's return type.

True, but, as the proposal states, the actual method invoked is ALWAYS  
the variant in PuttableByIndex or PuttableByKey; in other words, the  
invoked method is always the wrapper that returns void - if you do  
return something, and you use [] in the set/put context, whatever you  
return is neccessarily thrown away. It may help to imagine that this:

foo[bar] = RHS;

desugars to, after figuring out whether PuttableByIndex or  
PuttableByKey is intended:

((PuttableByIndex)foo).set(bar, RHS);

Note the cast - it ensures the expression's type is void, even if  
'foo' has a type that does return a value out of the put/set method.  
Because the API consideration of returning a value out of the put/set  
call is now no longer a part of PuttableByKey/SettableByIndex, each  
implementation that chooses to return something other than void gets  
to define their own semantics. We don't have to come up with 1  
semantic that must fit all implementations. We also preclude such a  
semantic to ever be used together with the [] assignment access, but I  
can live with that. We're still talking about, as Ruslan showed, a  
vanishingly small number of code-lines where pass-through assignment  
is even an issue.

>
> This does not apply because of the above. So I think it is important  
> that...
>

... so, it _does_ apply, and I still think the 'returns void' scenario  
is the best choice here. Nevertheless....

> >
> > foo[bar] = RHS
> >
> > will first retrofit RHS so that it 'fits' into foo (e.g. apply
> > autoboxing or unboxing), then this post-capture value is passed on  
> the
> > set/put method, and is duplicated on the stack as well for further
> > consumption.
>
> With this, everybody can be happy.
>


Yes, I admit that 'return void' appears to be a small minority here.