Principled method of lookup-or-insert in associative arrays?

[Tomek Sowiński]

Dnia 21-11-2010 o 02:02:35 Tyro[a.c.edwards] <nospam at home.com> napisał(a):

>> The harm is confusion. Now = on arrays always means aliasing, but with
>> your proposal, it may *sometimes* mean dupping. Imagine real-life code
>> with type aliasing and type inference in play, and trying to determine
>> whether some line makes a dupping string<->char[] conversion or not.
>
>  alias char[] firstClassString;
> alias firstClassString stringGold;
> alias stringGold lightAtEndOfTunnel;
> alias lightAtEndOfTunnel daBomb;
> alias daBomb iAmThe;
>  iAmThe man;
>  if I want to know the actual type of shiznit:
>  writeln(typeid(man)); // outputs char[]
>
>>  What would be the harm if everyone just put .(i)dup where it belongs?
>
>   Actually, I don't see any harm in using .(i)dup. However, my limited  
> experience does not allow me to think on the same level as you so I'm  
> just trying to understand your point a little better. That being said, I  
> still don't understand the gravity of the implied problem.

The status quo is imposing a tiny upfront tax on the writer of typing  
.(i)dup.
The proposal is imposing a minor tax on the reader of knowing another rule  
and, in case of convoluted code like above, minor tax of determining if  
this rule applies. Plus, some tax on the implementor to put this rule into  
the compiler.

The point is the aggregated tax imposed by the proposal is much greater  
because although minor it grows linearly with the number of readers (code  
is read much more often then written). And even with finite set of  
readers, the tax grows till infinity because with time people forget what  
they read, therefore the tax is collected anew.

And think of the gains -- dropping .(i)dup doesn't really buy you much  
anyway.

-- 
Tomek$