Indexing access for Lists and Maps considered harmful?

[Joseph D. Darcy]

Reinier Zwitserloot wrote:
> 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.

It may be the case that changing the desugaring to return void in these 
cases is the right thing to do in the end.

However, the mere existence of *some* puzzler should not be sufficient 
to derail a coin proposal.  I fully expect the language changes to 
enable new, initially unexpected program behavior; that does have to be 
more than compensated by the new, expected programs behavior that is 
allowed of course :-)

-Joe

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