On Tue, 13 Oct 2009 12:44:21 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
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").
I think the optimization translates to opAssign as well:
a[b] = c; => a.opAssign(b, c);
On Tue, 13 Oct 2009 12:37:50 -0400, Bill Baxter <wbax...@gmail.com> wrote:
Huh? It didn't sound to me like it would get rid of anything, except
for the use of the word "index" in many methods that have to do with
index operations. That just seems confusing to me. I think the
opIndexXxxAssign functions may need to be added, but adding them by
overloading existing names doesn't seem a win to me.
The point is to avoid having operator function names multiply out of
control. Re-examining it, I agree with you -- It makes little sense to
have an operator that involves an indexing lack the term Index.
If only there was a way to make the indexing orthogonal to the other
operation. For example something like:
struct X
{
private int[] arr;
opIndex(int idx) // declares a new "namespace" where idx is an
implicitly passed argument
{
int opAssign(int x)
{
arr[idx] = x;
return x;
}
}
}
I know this probably doesn't parse well, should opIndex be a keyword? or
an attribute?
-Steve
