Imported From: https://issues.scala-lang.org/browse/SI-8206?orig=1
Reporter: @densh
Affected Versions: 2.11.0-M8
See #8342

@retronym said:
Here's a contrived example when the intuitive interpretation is definitely assignment:

scala> object O { var x = 0 ; def foo = synchronized { x = 1 } }
defined object O

scala> O.foo; O.x
res0: Int = 1

@retronym said:
(I'm not against a move to make things unambiguous, BTW)

@densh said:
Some recent discussion on the topic: https://groups.google.com/forum/#!topic/scala-internals/MujIVZgbwEM

Ryan Hendrickson (ryan.hendrickson_bwater) said:
Man, I ran into a case today where I really wanted to write

doUpdate(_.copy(someField = _, anotherField = _))

but instead I had to write

doUpdate((a, b, c) => a.copy(someField = b, anotherField = c))

#firstworldprogrammingproblems

Not a bug, as spec'd, etc.; but am I correct in guessing that this proposed change would mean that the parser would recognize someField = _ as a named arg and not an expression, so that the former would be a valid anonymous function? Because that would be pretty nifty.

@lrytz said:
related to #8342, we plan to dis-ambiguate foo(a = x)

@lrytz this is no longer applicable thanks to the ambiguity going away in 2.13, right?