Revised RFC on range design for D2

[Christopher Wright]

KennyTM~ wrote:
> Andrei Alexandrescu wrote:
>> KennyTM~ 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)?
>>>
>>> Probably performance.
>>>
>>> Consider seeking to the end of a 100M-node single-linked list, and 
>>> increase its content by 1.
>>>
>>> But I agree that if something like .opIndexAddAssign() is not 
>>> defined, the compiler should fall back to use a.opIndexAssign(b, 
>>> a.opIndex(b)+c).
>>>
>>> (The same idea can be extended to properties and .opSlice() )
>>
>> Glad you brought opIndexAddAssign up. I think a good solution would 
>> avoid adding all opIndexXxxAssign functions. I think even opXxxAssign 
>> are undesirable.
>>
>> Andrei
> 
> Of course I don't want opIndexAddAssign either ;p.

That would be hell on generic programming, too. These would only be 
useful for collections, which are usually templated for the element 
type. Then your collection class would look like:

static if (SupportsAddition!(T))
{
	void opIndexAddAssign(T value) { ... }
}

And then I define a class:
class BigInt
{
	void opAddAssign (long i) { ... }
}

And it all goes to hell.

That means you have to do:
mixin (AdditionSupport!(T)());

string AdditionSupport(T)()
{
	foreach (method; __traits(getVirtualMethods, T, "opAddAssign"))
	{
		// codegen here
	}
}


And that only works because of a bug in __traits(getVirtualMethods) that 
returns final methods.

opIndex*Assign is just an unreasonable solution for generic programming.