could we always resolve `x += y` with `plusAssign` and `x + y` with `plus`? It's really a pity to gi...

# stdlib

[elect]

could we always resolve x += y with plusAssign and x + y with plus? It's really a pity to give up on that because of ambiguity

[dmitry.petrov]

Because there're immutable objects. Like strings, for example. You can't use plusAssign for them.

[elect]

?

[karelpeeters]

Or another example, Int. What do you expect a += 3 to do? Call Int.plusAssign? That doesn't exist, Ints are immutable.

[karelpeeters]

That just needs to be compiled to a = a + 3.

[elect]

I expect a += 3 to be always translated to a.plusAssign(3)

[dmitry.petrov]

And what should a.plusAssign(3) do for var a: Int?

[elect]

presents an error

[dmitry.petrov]

looks like "not an option", doesn't it?

[karelpeeters]

That's not how Kotlin/Java works. Let's say a 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]

I think of it really simple, if the class has the operator defined it will be overloaded

[elect]

Int doesnt

[elect]

we have smart casting, wouldn't be possible to have something similar detecting the receiver type and act consequently?

[elect]

it's really a blocker for me, in my glm lib I had to skip basically all the *Assign funcs for that

[elect]

and replace with functional ones, such as plus_

[karelpeeters]

You could make all of your objects immutable.

[elect]

not an option I'd say

[dmitry.petrov]

How exactly is that a blocker for you?
Currently, the rules are:
(1) If there's a compound assignment operator (opAssign), then a 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]

No sorry Dmitry, I misused the word blocker