Revised RFC on range design for D2

[Bill Baxter]

On Sat, Oct 4, 2008 at 12:07 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> 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

Wierd. But yet plain a[b] will still throw an exception?

--bb