On Tue, 13 Oct 2009 12:21:20 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
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)
I'm guessing you meant opAssign here, or meant to write +=?
Oh, sorry. I meant to write +=.
What do you think? I may be missing some important cases or threats.
It's simple, and gets rid of all opIndex operators except for opIndex
itself.
The question then becomes, what if you wanted to overload this?
a[b][c] += d;
You can do a[b] returns a ref. But then you now allow a[b] op x,
thereby possibly exposing a private piece of info. This may or may not
be important.
I like the way your idea is going.
Great. Indeed the proposed solution leaves a[b][c] += d problematic, and
also prevents this potential development:
a += b + c + d;
to be rewritten as:
a.opAddAssign(b, c, d);
Andrei
Well, that last case I'd prefer handled by something more generic, like an
opExpression(Expr, T...)(T params); (i.e. a way of doing expression
template/ BLADE like stuff, without the syntactic or runtime overhead.
