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

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

?

Or another example,

Int

. What do you expect

a += 3

to do? Call

Int.plusAssign

? That doesn't exist, Ints are immutable.

I expect

a += 3

to be always translated to

a.plusAssign(3)

And what should

a.plusAssign(3)

do for

var a: Int

?

presents an error

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

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.

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

You could make all of your objects immutable.

not an option I'd say

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.

No sorry Dmitry, I misused the word blocker