Scala 赋值评估为 Unit 而不是赋值的动机是什么？
I/O 编程中的一个常见模式是这样做：
while ((bytesRead = in.read(buffer)) != -1) { ...
但这在 Scala 中是不可能的，因为...
bytesRead = in.read(buffer)
.. 返回 Unit，而不是 bytesRead 的新值。
离开函数式语言似乎是一件有趣的事情。 我想知道为什么会这样做？
【问题讨论】：
标签： scala functional-programming io assignment-operator
只要你有一个间接引用类型，你就可以有一个解决方法。在幼稚的实现中，您可以将以下内容用于任意类型。
case class Ref[T](var value: T) {
def := (newval: => T)(pred: T => Boolean): Boolean = {
this.value = newval
pred(this.value)
}
}
然后，在您必须使用ref.value 之后访问引用的约束下，您可以将while 谓词编写为
val bytesRead = Ref(0) // maybe there is a way to get rid of this line
while ((bytesRead := in.read(buffer)) (_ != -1)) { // ...
println(bytesRead.value)
}
您可以以更隐含的方式对bytesRead 进行检查，而无需键入它。
【讨论】：
我不知道具体原因的内幕消息，但我的怀疑很简单。 Scala 使副作用循环难以使用，因此程序员自然会更喜欢 for-comprehensions。
它以多种方式做到这一点。例如，您没有在其中声明和改变变量的for 循环。在测试条件的同时，您不能（轻松）在 while 循环上改变状态，这意味着您经常必须在它之前和结束时重复突变。在while 块中声明的变量在while 测试条件中不可见，这使得do { ... } while (...) 的用处大大降低。以此类推。
解决方法：
while ({bytesRead = in.read(buffer); bytesRead != -1}) { ...
不惜一切代价。
作为另一种解释，也许 Martin Odersky 不得不面对一些源自这种用法的非常丑陋的错误，并决定从他的语言中取缔它。
编辑
David Pollack 拥有 answered 的一些实际事实，Martin Odersky 本人评论了他的答案这一事实清楚地证明了这一点，这证明了 Pollack 提出的与性能相关的问题论点。
【讨论】：
for 循环版本大概是：for (bytesRead <- in.read(buffer) if (bytesRead) != -1，这很好，只是它不起作用，因为没有foreach 和withFilter 可用！
顺便说一句：我发现最初的 while-trick 很愚蠢，即使在 Java 中也是如此。为什么不这样呢？
for(int bytesRead = in.read(buffer); bytesRead != -1; bytesRead = in.read(buffer)) {
//do something
}
当然，赋值出现了两次，但至少 bytesRead 在它所属的范围内，而且我不是在玩有趣的赋值技巧......
【讨论】：
也许这是由于command-query separation原则？
CQS 往往在 OO 和函数式编程风格的交汇处流行，因为它在具有或不具有副作用（即改变对象）的对象方法之间创建了明显的区别。将 CQS 应用于变量赋值比平时更进一步，但同样的想法也适用。
简要说明 CQS 为何有用：考虑一种假设的混合 F/OO 语言，该语言具有 List 类，该类具有 Sort、Append、First 和 Length 方法。在命令式 OO 风格中，可能想要编写这样的函数：
func foo(x):
var list = new List(4, -2, 3, 1)
list.Append(x)
list.Sort()
# list now holds a sorted, five-element list
var smallest = list.First()
return smallest + list.Length()
而在更实用的风格中，人们更有可能写这样的东西：
func bar(x):
var list = new List(4, -2, 3, 1)
var smallest = list.Append(x).Sort().First()
# list still holds an unsorted, four-element list
return smallest + list.Length()
这些似乎是在试图做同样的事情，但显然两者之一是不正确的，并且在不了解方法的行为的情况下，我们无法判断是哪一个。
但是，使用 CQS，我们会坚持如果 Append 和 Sort 更改列表，它们必须返回单位类型，从而防止我们在不应该使用第二种形式时创建错误。因此，副作用的存在也隐含在方法签名中。
【讨论】：
我主张让分配返回分配的值而不是单位。 Martin 和我对此反复讨论，但他的论点是，在堆栈上放置一个值只是为了在 95% 的时间内将其弹出是浪费字节码并且对性能产生负面影响。
【讨论】：
void。在 Scala 中，foo_=(v: Foo) 应该返回 Foo 如果赋值。
void (Unit)，赋值x = value 被翻译成等同于x.set(value);x.get(value)；如果值未使用，编译器会在优化阶段消除get-调用。在新的主要版本（由于向后不兼容）Scala 版本中，这可能是一个受欢迎的变化，并且对用户的刺激更少。你怎么看？
这发生在 Scala 中，它具有更“形式上正确”的类型系统。正式地说，赋值是一个纯粹的副作用语句，因此应该返回Unit。这确实有一些很好的后果；例如：
class MyBean {
private var internalState: String = _
def state = internalState
def state_=(state: String) = internalState = state
}
state_= 方法返回 Unit（正如 setter 所期望的那样）正是因为赋值返回 Unit。
我同意，对于复制流或类似的 C 样式模式，这个特定的设计决策可能有点麻烦。但是，它实际上总体上相对没有问题，并且确实有助于类型系统的整体一致性。
【讨论】：
将赋值用作布尔表达式并不是最好的风格。您同时执行两件事，这通常会导致错误。 Scalas 限制避免了意外使用“=”而不是“==”。
【讨论】：
我猜这是为了保持程序/语言没有副作用。
您所描述的是故意使用在一般情况下被认为是坏事的副作用。
【讨论】：
val a = b = 1 （想象val 在b 前面的“神奇”val）与val a = 1; val b = 1; 的情况。