A possible solution for the opIndexXxxAssign morass

[Michel Fortin]

On 2009-10-13 11:16:01 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Right now we're in trouble with operators: opIndex and opIndexAssign 
> don't seem to be up to snuff because they don't catch operations like
> 
> a[b] += c;
> 
> with reasonable expressiveness and efficiency.
> 
> Last night this idea occurred to me: we could simply use overloading 
> with the existing operator names. Consider:
> 
> a += b
> 
> gets rewritten as
> 
> a.opAddAssign(b)
> 
> Then how about this - rewrite this:
> 
> a[b] += c
> 
> as
> 
> a.opAddAssign(b, c);

I'd rewrite it as opIndexAddAssign(b, c); That way you can also rewrite:

	a[b..c] = d;

as

	opSliceAddAssign(b, c, d);


> There's no chance of ambiguity because the parameter counts are 
> different. Moreover, this scales to multiple indexes:
> 
> a[b1, b2, ..., bn] = c
> 
> gets rewritten as
> 
> a.opAddAssign(b1, b2, ..., bn, c)

That looks like a good idea, although I'd be a little tempted to put 
the variable-length part at the end so you can easily choose to use 
variadic arguments.

Also noteworthy: none of this work if you want to mix index and slices:

	a[b, c..d] = f;


> What do you think? I may be missing some important cases or threats.

Wasn't the bigger problem with operator overloading the fact that you 
have to redefine it for every primitive operator? I seem to recall you 
arguing for a way to overload all the operators at the same time. 
Where's that going?


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/