Fix Issue 8006: Property Binary Assignment Operators (Spec Change)

[JinShil]

Spec change to accompany dlang/dmd#7079

FYI: This does not address unary assignment operators (e.g. s.x++, ++s.x). I intend to implement that in a future pull request.

[dlang-bot]

Thanks for your pull request, @JinShil! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

• smaller, focused PRs are easier to review than big ones

• try not to mix up refactoring or style changes with bug fixes or feature enhancements

• provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Auto-close	Bugzilla	Description
✓	8006	Implement proper in-place-modification for properties

[JohanEngelen]

Here you should clarify what the semantics are (e.g. by mentioning equivalent code).
"appropriate getter and setter", is too vague to my taste (this is The Spec after all).

[JohanEngelen]

This also needs something like: Binary assignment can be used when the getter returns by ref. If the getter does not return by ref, and a setter is defined, binary assignment is equivalent with setter(getter() @ value), where @ is the operation.

[JohanEngelen]

(somewhere you should mention (and test in the other PR) the interplay with opBinary overloading)

[JinShil]

somewhere you should mention the interplay with opBinary overloading

I'm assuming you mean the opOpAssign overloads. Please correct me if I'm wrong.

The only ambiguity I see with the proposed implementation is when there is an alias thised property and a binary assignment operator overload (i.e. opOpAssign).

As an illustration of how things work today, consider the following code where there is an alias thised property x, and the assignment operator overload opAssign.

struct TInt
{
    int mX;

    @property int x() { return mX; }
    @property void x(int v) { mX = v; }

    int mB;
    void opAssign(int v) { mB = v; }

    alias x this;
}

void main()
{
    TInt t;
    t.x = 4;
    t = 5;    // Which do you think should be called? `x(5)` or `opAssign(5)`
	
    assert(t.mX == 4);
    assert(t.mB == 5);
}

This behavior is already defined in the spec at https://dlang.org/spec/class.html#alias-this

If the member is a class or struct, undefined lookups will be forwarded to the AliasThis member.

Since opAssign is not undefined t = 5 will call t.opAssign(5), and the binary assignment operators (i.e. opOpAssign) should work in the same way.

Since this behavior is already defined in the spec, I propose we don't duplicate it here in the Property Functions section.

and test in the other PR

I will be adding tests to the DMD PR to check that the implementation conforms to this specified behavior. Thank you for bringing it to my attention.

[JohanEngelen]

typo: forgot the dot.

[JohanEngelen]

The semantic interpretation of f.data+=3 ==> f.data(f.data()+3) is not true if the getter returns by ref. So this needs to be specified and clarified.

[andralex]

As mentioned in dlang/dmd#7079, it should be specified whether the object is evaluated once or twice and whether it's copied or not (should be evaluated once and never copied). At best the spec would define the operation through a lowering to simpler constructs.

[wilzbach]

LGTM as a start (pending addressing Andrei's comment)

[wilzbach]

See also: #1872