[Issue 21175] opAssign should be allowed to return void and let the compiler take care of chained assignments

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Feb 22 14:27:34 UTC 2023


https://issues.dlang.org/show_bug.cgi?id=21175

--- Comment #3 from Bolpat <qs.il.paperinik at gmail.com> ---
(In reply to Andrei Alexandrescu from comment #0)
> The return value of opAssign should always be `this` of type `ref T`.
> Literally anything else is a bug, and that makes for a poor convention. The
> compiler should take care of all that. Means user code is free of the
> convention and can return void.
> 
> Chained assignments should be lowered as follows. Currently e1 = e2 = e3 is
> lowered as:
> 
> e1.opAssign(e2.opAssign(e3))
> 
> It should be lowered as:
> 
> (ref T x) { x.opAssign(e3); e1.opAssign(x); }(e2)
> 
> meaning e2 is evaluated first, then e3 is evaluated and assigned to (the
> result of evaluating) e2, then then x is assigned to (the result of
> evaluating) e1.

The idea is right in principle, but what comes to my mind is C++ valarray. A
lot of operator= in there return void. I guess that’s because an assignment
operator should not return something else than a reference to the assigned
object. If that’s not possible, return `void`. D has better indexing operators
than C++:
`obj[index] = rhs` can lower to one function call of `opIndexAssign`, meaning
that the example is invalid in D; but that is due to index+assignment being a
special case in D. There are similar scenarios imaginable in which the issue is
relevant.

--


More information about the Digitalmars-d-bugs mailing list