Indexing access for Lists and Maps considered harmful?

[Reinier Zwitserloot]

You realize this is going to be an instant java puzzler, right? I  
thought one of the soft goals of project coin is to attempt to  
sidestep obvious puzzlers.

I also admit that I cannot come up with any situation where the  
expression:

thingA[thingB] = thingC;

evaluating to something that ISNT 'thingC' (or void) is going to be  
the logical, not confusing choice.


Suggestion: Define this operation to return void regardless of the  
underlying method implementation's actual return value. That way, if  
in the future a solid use case for letting the method invocation  
decide return type and value is found, a change can be made without  
breaking old code. If, on the other hand, there's a clamour for  
letting this expression return 'thingC', that can be added to a future  
version of java as well.

In other words, picking EITHER "That evaluates to thingC" OR "That  
evaluates to whatever the put method returns" is a choice you must  
make for the rest of the life of the java language. On the other hand,  
picking "That is a statement and not an expression (e.g. evaluates to  
void)" is not a life-long choice; if it ends up being a bad choice,  
you can switch to either alternative later without any pain other than  
filing a purely additive language change.


The only obvious disadvantage to 'return void' that I can see is that  
its inconsistent with both the current behaviour of the assignment  
operator AND the desugaring idea, whereas the alternatives are  
consistent with one behaviour and inconsistent with the other. Then  
again, with 'returns thingC' and 'returns returntype of put method',  
the inconsistent behaviour is silent, puzzler-esque, and going to  
cause hundreds of people subtle and hard to find bugs, whereas in the  
'returns void' scenario, there is no confusion at all, as the compiler/ 
editor will instantly tell you that the assignment is a statement and  
not an expression.


I just talked myself into throwing my overwhelming support behind the  
return void choice. Both other choices lead to long bug hunts and  
confusion that can only be solved by experimenting or grabbing the  
JLS, whereas void can't lead to bug hunts and any confusion it  
engenders is instantly assuaged by a compiler hint.

  --Reinier Zwitserloot



On 2009/23/06, at 07:46, Joseph D. Darcy wrote:

> My current preference is to keep a simple desugaring of the indexing  
> operators into method calls.  While collection usage would certainly  
> be a common case, there are probably other to-be-written APIs that  
> would benefit from the translation into method calls.
>
> -Joe
>
> Reinier Zwitserloot wrote:
>> I agree that the expression "map[c] = d" returning the OLD value  
>> of  map[c] (e.g. usually null) is unacceptable behaviour, but I  
>> think this  propsoal would fare just fine if this form of operation  
>> is defined to  return void and not 'd', in order to avoid  
>> confusion. There are many  code bases that never use pass-through  
>> assignment, and the workaround  (write it out...) is by definition  
>> not more boilerplate and noise than  what we have now.
>>
>>
>> I do lean slightly to preferring the expression to return 'd', and  
>> not  void, nor 'old mapping of c'.
>>
>>  --Reinier Zwitserloot
>>
>>
>>
>> On 2009/22/06, at 22:40, Lawrence Kesteloot wrote:
>>
>>
>>> On Mon, Jun 22, 2009 at 12:19 PM, Joseph D.  
>>> Darcy<Joe.Darcy at sun.com>  wrote:
>>>
>>>> map["a"] = map["b"] = "c";
>>>>
>>>> the new value for key "a" would be the old mapping of "b" and not
>>>> necessarily "c" because a call to the put method returns the old   
>>>> value.
>>>>
>>> There is no way that:
>>>
>>>   map["b"] = "c"
>>>
>>> can return anything other than "c". Returning the old value or
>>> returning void would violate 40 years of C-based expectations
>>> (including the identical construct in the STL). It must either  
>>> return
>>> "c" or not be implemented at all.
>>>
>>> Lawrence
>>>
>>>
>>
>>
>>
>