elect
10/09/2017, 5:45 PMx += y
with plusAssign
and x + y
with plus
? It's really a pity to give up on that because of ambiguitydmitry.petrov
10/09/2017, 5:47 PMelect
10/09/2017, 5:47 PMkarelpeeters
10/09/2017, 5:55 PMInt
. What do you expect a += 3
to do? Call Int.plusAssign
? That doesn't exist, Ints are immutable.karelpeeters
10/09/2017, 5:56 PMa = a + 3
.elect
10/09/2017, 5:57 PMa += 3
to be always translated to a.plusAssign(3)
dmitry.petrov
10/09/2017, 5:58 PMa.plusAssign(3)
do for var a: Int
?elect
10/09/2017, 5:59 PMdmitry.petrov
10/09/2017, 5:59 PMkarelpeeters
10/09/2017, 6:00 PMa
is evaluated to 5, the actual call would then be 5.plusAssign(3)
. What is the "object" 5
supposed to do with this? It doesn't know about your variable a
, and 5
itself is immutable.elect
10/09/2017, 6:00 PMelect
10/09/2017, 6:00 PMInt
doesntelect
10/09/2017, 6:00 PMelect
10/09/2017, 6:02 PM*Assign
funcs for thatelect
10/09/2017, 6:02 PMplus_
karelpeeters
10/09/2017, 6:02 PMelect
10/09/2017, 6:03 PMdmitry.petrov
10/09/2017, 6:59 PMa op= b
translates to <get-a>().opAssign(b)
.
(2) Otherwise, a op= b
translates to <set-a>(<get-a>().op(b))
.
Compound assignment operator convention (case (1)) is there exactly for mutable objects. It can't work uniformly on JVM without additional allocations, and it is highly unlikely these rules would be changed.
If you have mutable class C, and do not want to allocate new instances on compound operations, then you should define corresponding compound assignment operators. It could be possible to derive regular operators from compound assignment (feature request would be nice), not the other way around.elect
10/09/2017, 9:15 PM