Revised RFC on range design for D2

[Andrei Alexandrescu]

Sergey Gromov wrote:
> Fri, 03 Oct 2008 09:02:07 -0500,
> Andrei Alexandrescu 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.
>>
>> Another problem (assuming the above is fixed) is that b will be looked 
>> up twice in the hash.
> 
> The latter is not a problem if you always try to use a[b] as an lvalue 
> before trying anything more specific.  Though it makes the former even 
> harder to fix.  Probably there should be another opIndex for a context 
> where the user expects a non-existent element to be created:
> 
> ref T opIndexCreate(size_t i)
> 
> When compiler sees "a[b] += c" it first calculates the type of "a[b]" in 
> an assignment context.  In case of indexing it means considering 
> a.opIndexCreate, then a.opIndex, and finally the built-in indexing.  
> Then it checks whether that type is an lvalue or implements the 
> requested assignment operation.  If neither is true then compiler falls 
> back to a.opIndexAssign(b, ...) as a special backward-compatibility 
> case.

Yah, Walter, Bartosz and I discussed this (under the name 
opIndexLvalue). It does have a problem with sparse arrays. In a sparse 
array, a[b] = 0 means the array should actually erase slot at position b 
(or not insert it if it was missing in the first place). This suggests 
that a more flexible mechanism would be to have a place where the 
container, the index, and the assigned value are all available to the 
same function.

Andrei