Calling opAssign on an rvalue should be illegal

[jmdavis]

void main ()
{
    foo() = 42;
}

int foo()
{
    return 0;
}

gives the error

q.d(3): Error: cannot modify expression `foo()` because it is not an lvalue
    foo() = 42;
       ^

However,

void main ()
{
    foo() = S.init;
}

S foo()
{
    return S.init;
}

struct S
{
    int i;

    void opAssign(S s)
    {
        this.i = s.i;
    }
}

compiles just fine.

I don't see why overloading opAssign should behave any differently in this respect than the built-in assignment does. It just makes it so that you can accidentally assign to an rvalue and have the result disappear on you without getting any errors about doing something nonsensical.

opOpAssign has the same problem: #19061

[dkorpel]

The increment operator is similar as well:

struct Int
{
    int v;
    void opUnary(string op : "++")() {}
}

void main()
{
    3++; // Error: cannot modify constant `3`
    Int(3)++; // Fine
}

[dkorpel]

The spec says operator overloading works by rewriting to method calls, and struct methods can be called on rvalues despite the this parameter being ref. foo().opAssign(S.init) is legal, therefore foo() = S.init is. Regular ref parameters don't accept rvalues, but with #17068 there is pressure to remove this limitation.

We could add special cases to operator overloading, but perhaps we can consider a more general solution because I found that some people specifically test that rvalues don't pass to ref parameters of their functions: dlang/phobos#9092

So it looks like what we're looking for is a parameter storage class to signifiy 'ref but no rvalues'. On the other hand, we really don't need more attributes 😕

[jmdavis]

Honestly, I think that having ref accept rvalues is a terrible idea, but I also don't want to spend the energy to fight that battle. I suppose that if that gets merged, in the general case, we can always just add rvalue overloads with @disable on them (assuming that works) and no body so that they become an error in the cases where people care enough to prevent the behavior, and no additional attribute would be required (ugly as that would be). And no, we don't want more attributes. We have too many already.

Either way, if an operator on a built-in type doesn't work with rvalues, then I don't think that it should work with user-defined types either even if that requires special casing those operators regardless of what happens with ref. It's just a source of bugs to allow it. And since the this parameter is invisible, unless we added another function attribute, it's not like there's any way to make it so that an arbitrary member function doesn't accept rvalues for the this parameter.