On 2009-10-13 11:16:01 -0400, Andrei Alexandrescu
<seewebsiteforem...@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.for...@michelf.com
http://michelf.com/
