An implementation of binary assignment operators for @property
functions has been submitted to the DMD pull request queue at
https://github.com/dlang/dmd/pull/7079. It addresses the
following issues:
Issue 8006 - Implement proper in-place-modification for properties
https://issues.dlang.org/show_bug.cgi?id=8006
------------------------------------------------------------------
This is the primary issue motivating the pull request. The pull
request is only a partial resolution of this issue; it implements
binary assignment operators (e.g. `s.x += 2`), but not unary
assignment operators (e.g. `s.x++`). The plan is to implement
unary assignment operators in a separate pull request after the
fate of the binary assignment operators pull request is decided.
Issue 18187 – std.bitmap fields should be lvalues
https://issues.dlang.org/show_bug.cgi?id=16187
-------------------------------------------------
This is a more real-world example where binary assignment
operators would be beneficial, as bit fields are not individually
addressable.
Issue 15231 - opOpAssign allows assignment to rvalue
https://issues.dlang.org/show_bug.cgi?id=15231
----------------------------------------------------
While the pull request does not actually resolve the error
illustrated in this issue, it demonstrates how a user desired
binary assignment operators for @property functions so much that
(s)he attempted to implement them indirectly by modeling the
value type as a struct and overloading its operators. Had binary
assignment operators been implemented the user probably would not
have had any need expend such effort.
Like the other users that commented in the issues above, I was a
bit dismayed to discover that binary assignment operators were
not implemented for @property functions. When I submitted the
pull request I was under the assumption that the only reason they
weren’t implemented was because noone had gotten around to it yet.
Walter has requested that I make this forum post to inform the
community of this change in an effort to discuss its merits
and/or shortcomings.
We ask for your comments whether they be in approval or
disapproval of this pull request so we can determine the best way
forward.
Thank you,
Michael V. Franklin
