Bug 15231 – opOpAssign allows assignment to rvalue

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2015-10-21T12:52:11Z
Last change time
2024-12-13T18:45:26Z
Assigned to
No Owner
Creator
ryan
See also
https://issues.dlang.org/show_bug.cgi?id=8006
Moved to GitHub: dmd#19061 →

Comments

Comment #0 by ryan — 2015-10-21T12:52:11Z
unittest { struct MyInt { int _val; auto opBinary(string op)(int other) { return mixin("_val"~op~"other"); } void opOpAssign(string op)(int other) { _val = mixin("_val"~op~"other"); } } struct Foo { int _i; MyInt _mi; auto i() { return _i; } auto mi() { return _mi; } auto i(int val) { return _i = val; } auto mi(int val) { return _mi = MyInt(val); } } auto f = Foo(1, MyInt(1)); static assert(!__traits(compiles, f.i += 1)); // f.i is an rvalue static assert(!__traits(compiles, f.mi += 1)); // f.mi should be an rvalue } The final assert fails.f.mi is not an lvalue, and therefore f.mi += 1 should not compile. It deceptively appears to increment `mi` while truly doing nothing. The compiler disallows this for builtin types (e.g. int) but somehow the use of opOpAssign bypasses this check. Ideally, I'd love to have support for in-place property modification (https://issues.dlang.org/show_bug.cgi?id=8006), but failing that, I think this should be disallowed to avoid confusion. P.S. not sure whether this belongs in DMD or druntime
Comment #1 by default_357-line — 2021-11-18T11:42:46Z
https://run.dlang.io/is/pqAj9b Just ran into this. Annoying! Not caught by @safe or -dip1000 either.
Comment #2 by robert.schadek — 2024-12-13T18:45:26Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19061 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB