Scala 优先考虑隐式转换而不是“自然”转换。操作...为什么？这是一个错误吗？或者我做错了什么？

Question

当然，这个简单的测试按预期工作：

scala> var b = 2
b: Int = 2

scala> b += 1   

scala> b
res3: Int = 3

现在我将其纳入范围：

class A(var x: Int) { def +=(y:Int) { this.x += y } }
implicit def int2A(i:Int) : A = new A(i)             

我正在定义一个新类并对其进行 += 操作，并在我想要将 Int 添加到 A 时进行方便的隐式转换整数值。

当“A”类根本不是表达式的一部分时，我从未预料到这会影响我的常规 Int 操作的行为方式。

但确实如此：

scala> var b:Int = 0
b: Int = 0

scala> b += 1

scala> b  
res29: Int = 0

scala> b += 2

scala> b
res31: Int = 0

这里似乎发生的是 b:Int 被隐式转换为“A”，它没有绑定到任何变量，然后对其调用 += ，丢弃结果。

Scala 似乎对已经定义为 Ints 的自然 += 行为（编译器魔术，而不是实际方法）给予隐式转换高度优先。常识和 C++ 背景告诉我，只有在万不得已时才应调用隐式，否则编译会失败。这引出了几个问题……

• 为什么？这是一个错误吗？是设计使然吗？
• 有没有解决方法（除了不使用“+=”来执行 DSL 的“+=”操作）？

谢谢

Answer 1

正如其他人所指出的，Int 不能有 +=“方法”，因为 Int 是不可变的。相反，x += 1 被视为 x = x + 1 的简写形式，但前提是不存在
在类型上定义的名为 += 的方法。因此方法解析优先。

鉴于 Scala 允许您定义 += 方法，并且还允许您对变量执行 +=，我们是否可以更改两者的优先级？即首先尝试扩展 +=，并且仅当搜索名为 += 的方法失败时才尝试扩展 +=？

理论上是的，但我认为这会比当前的计划更糟糕。实际上，不。 Scala 的集合库中有很多类型都定义了 + 方法
非破坏性加法和破坏性加法的 += 方法。如果我们切换了优先级，那么像这样的调用

  myHashTable += elem

将扩展为

  myHashTable = myHashTable + elem

So 它将构造一个新的哈希表并将其分配回变量，而不是简单地更新元素。这不是明智之举...

Answer 2

来自 Scala 编程，第 17 章：

每当你写 a += b，并且 a 确实如此
Scala 不支持名为 += 的方法
将尝试将其解释为 a = a + b。

类 Int 不包含方法 +=。然而类A提供了+=方法。这可能会触发从 Int 到 A 的隐式转换。

Answer 3

我不认为这是一个错误。
实际上，Int只有“+”方法而没有“+=”方法。
如果不存在其他具有“+=”方法的隐式，则 b += 1 将在编译时转换为 b = b + 1。

Answer 4

Scala 似乎比已经定义为 Ints 的自然 += 给予隐式转换更高的优先级。

你说的是哪个版本的 Scala？我不知道有任何版本在 Int 上有 += 方法。当然，仍然受支持的版本都没有这样做，那一定是您那里的某个真正古老版本。

由于 Int 上没有 +=，但您在 上调用一个 += 方法Int，Scala 尝试通过隐式转换来满足该类型约束。

Answer 5

即使不顾 Eastsun 的解释，这似乎是一个错误，它应该在尝试 += 的隐式转换之前尝试 b=b+1 转换。

请通过发送电子邮件至 [email protected] 或访问 n4.nabble.com/Scala-User-f1934582.html。如果它是一个错误，那就是它会被注意到并修复的地方。