http://d.puremagic.com/issues/show_bug.cgi?id=3188

           Summary: remove opIndexAssign from the language
           Product: D
           Version: 2.031
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: k-foley@onu.edu


Despite being redundant, my main gripe with opIndexAssign is that it can even get in the way. For instance:

---

import std.stdio;

struct Arr(size_t W, size_t H, T)
{
    T[W * H] arr;

    this(T[W*H] rhs)
    {
        arr = rhs;
    }

    ref T opIndex(size_t row, size_t col)
    {
        return arr[row + W*col];
    }
}

int main()
{
    auto a = Arr!(2, 2, int)( [1, 2, 3, 4] );

    writeln( "a[1, 1] = ", a[1, 1] ); // a[1, 1] = 4

    a[1, 1] += 2;
    writeln( "a[1, 1] = ", a[1, 1] ); // a[1, 1] = 6

    // This requires opIndexAssign, but for no good reason
    //a[1, 1] = 42;
    //writeln( "a[1, 1] = ", a[1, 1] );

    return 0;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
           Platform|Other                       |All




--- Comment #1 from Stewart Gordon <smjg@iname.com>  2009-07-17 10:24:56 PDT ---
(In reply to comment #0)
> Despite being redundant, my main gripe with opIndexAssign is that it can even get in the way. For instance:

opIndexAssign isn't redundant, just as property setters aren't redundant.

>     // This requires opIndexAssign, but for no good reason
>     //a[1, 1] = 42;

Given that opIndexAssign doesn't occur in your code, removing opIndexAssign from the language isn't going to magically make this work.

Here's the compiler output (DMD 2.031 Win):
----------
C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd bz3188.d
bz3188.d(28): Error: operator [] assignment overload with opIndex(i, value)
illegal, use opIndexAssign(value, i)
----------

Really, the problem is that opIndex is only meant to work on op=, ++ and --, not = itself.

http://www.digitalmars.com/d/2.0/operatoroverloading.html
"Note: To use array index overloading with the op=, ++, or -- operators, have
the opIndex function return a reference type. This reference is then used as
the lvalue for those operators."

The way resolving = ought to work:
- first look for a matching opIndexAssign
- if none, look for an opIndex with a ref return

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188





--- Comment #2 from Kyle Foley <k-foley@onu.edu>  2009-07-17 12:12:06 PDT ---
> Given that opIndexAssign doesn't occur in your code, removing opIndexAssign from the language isn't going to magically make this work.

I don't see why not.  "a[1, 1] = 42;" should just become "a.opIndex(1, 1) = 42;" rather than do something special because the "=" is there.  I am under the impression that opIndexAssign is there only because return by reference was not available at the time of designing operator overloads.  But I would be satisfied with your proposed fix anyways.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188





--- Comment #3 from Stewart Gordon <smjg@iname.com>  2009-07-17 12:35:45 PDT ---
(In reply to comment #2)
>> Given that opIndexAssign doesn't occur in your code, removing opIndexAssign from the language isn't going to magically make this work.
> 
> I don't see why not.  "a[1, 1] = 42;" should just become "a.opIndex(1, 1) = 42;" rather than do something special because the "=" is there.

Welcome to D.  The expansion of a given expression form is by no means fixed. Already an example of this is that many operators can be overloaded either by the left operand's type (using the regular op* methods) or the right operand's type (using the op*_r methods).  In the same way, the existence of opIndexAssign does nothing whatsoever to prevent the compiler from expanding it to something else instead if the type in question has no opIndexAssign.  And even then, that something else would have to be implemented, which is another piece of work.

> I am under the impression that opIndexAssign is there only because return by reference was not available at the time of designing operator overloads.

That's one reason.  The other reason is that it can do many things that a ref
return can't, such as
- converting the value to an internal representation
- validating the set value
- calling some external API to set the value
- triggering side effects beyond setting the value in memory

It's the exact same reason that we have properties.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com




--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com>  2009-07-17 12:55:21 PDT ---
(In reply to comment #3)
> That's one reason.  The other reason is that it can do many things that a ref
> return can't, such as
> - converting the value to an internal representation
> - validating the set value
> - calling some external API to set the value
> - triggering side effects beyond setting the value in memory

All of these things are doable from a returned struct which contains opAssign.

I agree with the reporter that opIndexAssign is a feature that we could do without, although you are correct in that removing opIndexAssign doesn't solve his problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188





--- Comment #5 from Kyle Foley <k-foley@onu.edu>  2009-07-17 13:19:31 PDT ---
(In reply to comment #3)
> Welcome to D.

Thank you :)

> In the same way, the existence of
> opIndexAssign does nothing whatsoever to prevent the compiler from expanding it
> to something else instead if the type in question has no opIndexAssign.

What else could it be?

> > I am under the impression that opIndexAssign is there only because return by reference was not available at the time of designing operator overloads.
> 
> That's one reason.  The other reason is that it can do many things that a ref
> return can't, such as
> - converting the value to an internal representation
> - validating the set value
> - calling some external API to set the value
> - triggering side effects beyond setting the value in memory
> 
> It's the exact same reason that we have properties.

But properties are not operators.  If opIndexAssign must exist, then why doesn't, for example, opStarAssign also exist?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188





--- Comment #6 from Stewart Gordon <smjg@iname.com>  2009-07-25 05:03:46 PDT ---
(In reply to comment #5)
> (In reply to comment #3)
>> In the same way, the existence of opIndexAssign does nothing whatsoever to prevent the compiler from expanding it to something else instead if the type in question has no opIndexAssign.
> 
> What else could it be?

The opIndex with ref return already being talked about, of course.

> But properties are not operators.  If opIndexAssign must exist, then why doesn't, for example, opStarAssign also exist?

To be honest, I'm not sure either.  Aside from the fact that "star" doesn't describe the semantics of any D operator, at least it would enable bit pointers that use the same notation as normal pointers.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188





--- Comment #7 from Sobirari Muhomori <maxmo@pochta.ru>  2009-07-27 02:18:02 PDT ---
opMulAssign exists and return by ref was meant to solve an unrelated problem, I believe. It's not a replacement for assign operators.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188


Witold Baryluk <baryluk@smp.if.uj.edu.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baryluk@smp.if.uj.edu.pl




--- Comment #8 from Witold Baryluk <baryluk@smp.if.uj.edu.pl>  2009-07-27 04:52:22 PDT ---
I just want to comment about this controversial issue. I'm using opAssignIndex, and in any way changing it to opIndex + ref return, will make my code impossible to write or very slow. opIndex and opAssignIndex isn't only usefull for arrays!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3188





--- Comment #9 from Kyle Foley <k-foley@onu.edu>  2009-07-27 07:43:43 PDT ---
(In reply to comment #7)
> opMulAssign exists and return by ref was meant to solve an unrelated problem, I believe. It's not a replacement for assign operators.

The problem is that opIndex and opIndexAssign use the same syntax, whereas the others (e.g. opMul and opMulAssign) use a distinct syntax: opMul is * and opMulAssign is *=.  Now that ref return is available, I see no reason to keep opIndexAssign around.  The added complexity is not necessary.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------