Revised RFC on range design for D2

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Sat, Oct 4, 2008 at 11:57 AM, KennyTM~ <kennytm at gmail.com> wrote:
>> Bill Baxter wrote:
>>> On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>> Sergey Gromov wrote:
>>>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>>>> Andrei Alexandrescu wrote:
>>>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to
>>>>>> ask...
>>>>>> any ideas? :o)
>>>>>>
>>>>>> One goal is to fix opIndexAssign and make it work similar to the way it
>>>>>> works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
>>>>>> test
>>>>>> bed.
>>>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>>> One problem is that for a hashtable that does not have b yet, opIndex
>>>> will
>>>> throw an exception.
>>> I don't see why you expect   a[b] += c to work on a key for which a[b]
>>> is undefined.  If it's undefined how can you increment it?
>> Actually I did use it once to count things, so I could just use a[b]++
>> instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.
> 
> But D hashmaps don't work like that.
> I guess std::map in C++ does behave like that, so that could explain
> why Andrei would expect that behavior from a map data structure.

No, it's not std::map. Actually, much to everyone's confusion, Walter 
hacked a[b]++ and ++a[b] to automatically insert typeof(a[b]).init at 
slot b in a if it didn't exist. Try it!

Andrei