【问题讨论】：
标签： scala overloading
重载使得将方法提升为函数有点困难：
object A {
def foo(a: Int) = 0
def foo(b: Boolean) = 0
def foo(a: Int, b: Int) = 0
val function = foo _ // fails, must use = foo(_, _) or (a: Int) => foo(a)
}
您不能选择性地导入一组重载方法中的一个。
在尝试应用隐式视图以使参数适应参数类型时，更有可能出现歧义：
scala> implicit def S2B(s: String) = !s.isEmpty
S2B: (s: String)Boolean
scala> implicit def S2I(s: String) = s.length
S2I: (s: String)Int
scala> object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }
<console>:15: error: ambiguous reference to overloaded definition,
both method foo in object test of type (b: Boolean)Int
and method foo in object test of type (a: Int)Int
match argument types (java.lang.String)
object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }
它可以悄悄地使默认参数不可用：
object test {
def foo(a: Int) = 0;
def foo(a: Int, b: Int = 0) = 1
}
就个人而言，这些原因并不能迫使您完全避免超载。我觉得我错过了一些更大的问题。
更新
证据堆积如山。
更新 2
更新 3
scala> object O { def apply[T](ts: T*) = (); def apply(f: (String => Int)) = () }
defined object O
scala> O((i: String) => f(i)) // oops, I meant to call the second overload but someone changed the return type of `f` when I wasn't looking...
【讨论】：
_.foo 问题的错误是 Scala 的有限类型推断，而不是重载。您回答了这个问题，但其中一些原因是由于 Scala 中可以改进的其他弱点。重载比运行时向下转换析取更有效，或者名称的笛卡尔积是嘈杂的并且与共享语义断开连接。
addIntToDouble、addDoubleToInt，即名称的笛卡尔积，而不是每个常见语义的静态类型。用命名代替打字似乎是倒退的。 Java got more things correct 可能比我们认识的要多。
Gilad 和 Jason（retronym）给出的理由都是尽可能避免重载的很好理由。 Gilad 的原因集中在为什么重载通常会出现问题，而 Jason 的原因则集中在为什么它在其他 Scala 特性的上下文中会出现问题。
在 Jason 的列表中，我要补充一点，重载与类型推断的交互作用很差。考虑：
val x = ...
foo(x)
x 推断类型的更改可能会改变调用哪个 foo 方法。 x 的 值 不需要改变，只是 x 的推断类型，这可能由于各种原因而发生。
出于所有给出的原因（还有一些我确定我忘记了），我认为方法重载应该尽可能少用。
【讨论】：
foo 的语义应该相同，否则设计不正确。至于限制奇异级联推理更改的范围，公共方法应始终声明其返回类型。我认为这是影响版本之间 Scala 二进制兼容性的问题之一。
我认为该建议并不是特别针对 scala，而是针对一般的 OO（到目前为止，我知道 scala 应该是 OO 和功能之间的最佳选择）。
覆盖很好，它是多态性的核心，也是面向对象设计的核心。
另一方面，重载问题更大。使用方法重载很难辨别哪个方法会真正被调用，而且它确实经常引起混淆。也很少有理由说明为什么真的需要重载。这个问题大部分时间都可以通过其他方式解决，我同意超载是一种气味。
这里是an article，它很好地解释了我所说的“重载是混乱的根源”，我认为这是不鼓励它的主要原因。它适用于 java，但我认为它也适用于 scala。
【讨论】：