Revised RFC on range design for D2

[Sergey Gromov]

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.