看这个例子：
def hello(a:String,b:String) = println(a + ":" + b)
val m1 = hello("aaa",_ )
m1("bbb")
它不能被编译,我需要添加类型到partial方法：
val m1 = hello("aaa",_: String)
为什么Scala不知道方法的第二个参数hello是String？
Scala的类型推断是基于流的.方法和函数需要显式参数类型,用于推断其他类型.不能从方法或函数体推断参数类型.然而,有时,参数类型是从外部上下文中知道的,然后不必被标记.两个例子,
val f: String => Unit = hello("aaa",_)
val s = Seq(1,2).map(_+1) // Seq[Int].map expects a function of Int argument type
以下是Martin Odersky关于Scala类型推理与ML和Haskell相比的限制的引用.挑战包括Scala的超载,记录选择和子类型化,以及需要保持简单,
The reason Scala does not have Hindley/Milner type inference is that
it is very difficult to combine with features such as overloading (the
ad-hoc variant,not type classes),record selection,and subtyping.
I’m not saying impossible — there exist a number of extensions that
incorporate these features; in fact I have been guitly of some of them
myself. I’m just saying it’s very difficult to make this work well in
practice,where one needs to have small type expressions,and good
error messages. It’s not a shut case either — many researchers are
working on pushing the boundaries here (look for instance at Remy’s
MLF). But right now it is a tradeoff of better type inferencing vs
better support for these features. You can make the tradeoff both
ways. The fact that we wanted to integrate with Java tipped the scales
in favor of subtyping and away from Hindley/Milner.
资料来源：评论在帖子Universal Type Inference is a Bad Thing.
