On Tue, 13 Oct 2009 20:34:06 +0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Tue, 13 Oct 2009 12:28:05 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
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);
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)
What do you think? I may be missing some important cases or threats.
Andrei
How about this case:
a[b1..b2] = c;
?
I could be solved if b1..b2 would return some built-in range type,
defined in object.d, though.
That already has an operator:
int opSliceAssign(int v, size_t x, size_t y);
a[3..4] = v; // same as a.opSliceAssign(v,3,4);
I meant:
a[b1..b2] += c;
Another thing I dislike about this proposal is that "a[b] += c;"
translates into "opAddAssign" and doesn't mention "index" while "a[b] =
c;" does ("opIndexAssign").
