Scala 2.8: _ behaviour changed?

Question

Using XScalaWT, this compiled under Scala 2.7:

class NodeView(parent: Composite) extends Composite(parent) {
  var nodeName: Label = null

  this.contains(
    label(
      nodeName = _
    )
  )
}

With 2.8.0 RC1, I get this error:

type mismatch; found : main.scala.NodeView required: org.eclipse.swt.widgets.Label

The types are:

label(setups: (Label => Unit)*)(parent: Composite) : Label
contains(setups: (W => Unit)*) : W

So it looks like _ now binds to the outer function instead of inner.

Is this change intentional?

UPDATE: Here is a minimized example:

Scala 2.7.7:

scala> var i = 0
i: Int = 0

scala> def conv(f: Int => Unit) = if (_:Boolean) f(1) else f(0)    
conv: ((Int) => Unit)(Boolean) => Unit

scala> def foo(g: Boolean => Unit) { g(true) }    
foo: ((Boolean) => Unit)Unit

scala> foo(conv(i = _))    

scala> i    
res4: Int = 1

Scala 2.8.0RC3:

scala> var i = 0
i: Int = 0

scala> def conv(f: Int => Unit) = if (_:Boolean) f(1) else f(0)
conv: (f: (Int) => Unit)(Boolean) => Unit

scala> def foo(g: Boolean => Unit) { g(true) }
foo: (g: (Boolean) => Unit)Unit

scala> foo(conv(i = _))
<console>:9: error: type mismatch;
 found   : Boolean
 required: Int
       foo(conv(i = _))
                  ^

scala> foo(conv(j => i = j))

scala> i
res3: Int = 1

Interestingly enough, this works:

scala> foo(conv(println _))
1

Answer 1

I noticed the same thing and asked on Dave's blog:

http://www.coconut-palm-software.com/the_new_visual_editor/doku.php?id=blog:simplifying_swt_with_scala#comment__930ba2f0a020203873d33decce01ebc2

No answer there yet though. Just as you're saying, it seems like the _ binds to the outer closure rather than the inner one.

Changing

nodeName = _

to

x => nodeName = x

fixes the problem.

Answer 2

Here is the answer I got from Lukas Rytz on the scala-user list:

Hi Alexey,

there has been a change in semantics when we introduced named arguments. An expression

foo(a = _)

used to be parsed as follows:

foo(x => a = x)

In 2.8, "a" is treated as a named argument, i.e. the expression is parsed as:

x => foo(a = x)

I will add a migration warning for this change.