A possible solution for the opIndexXxxAssign morass

[Steven Schveighoffer]

On Tue, 13 Oct 2009 12:44:21 -0400, Denis Koroskin <2korden at 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 <wbaxter at 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