scala 2.9：计划使用默认参数对函数参数进行类型推断？

Question

我刚刚开始使用 Scala。我一直在使用 Python 进行研究编程，并且正在转换一个相当大（约 4000 行）的 Python 程序。

几点评论：

1. 现在看来是参与 Scala 的好时机，因为 2.8 中添加了很多好东西。
2. 另一方面......我想知道为什么Scala似乎没有像样的IO包，以及为什么这似乎不是一个优先事项。在大多数语言中，IO 被认为是最基本的操作之一，并且语言的某些部分通常是专门设计的，以便 IO 正常工作。例如，Python 中的 IO 库似乎是该语言最古老、最稳定的部分之一（至少在其界面上）。然而两年前的评论说“Source.fromFile() 是一个巨大的黑客攻击，等到某某完成新的 IO 包”——我看不到完成这个的任何进展。更糟糕的是，Source.fromFile().getLines()——无论是否被黑客入侵，都是普遍宣传的接口——被 2.9.0.1 中的更改完全破坏（请参阅< a href="https://issues.scala-lang.org/browse/SI-4662">https://issues.scala-lang.org/browse/SI-4662）。显然，对于这个最基本的 IO 接口根本没有进行回归测试，这是一个坏兆头。
3. 类型擦除非常糟糕，我真的很想知道为什么在 Scala 中决定将其保留下来。是的，我知道 Java 具有类型擦除功能，并且 Scala 是构建在 JVM 上的，但最终需要添加显式可见的内容，例如清单、专门化注释等来解决类型擦除的问题真的很难闻……我最终感觉 Scala 设计者将意识到这一切的愚蠢之处，并被迫实现正确的泛型类型，此时他们将然后有很多废弃不需要的东西。

我的问题是：

是否计划为具有默认参数的函数参数添加类型推断？写这样的东西有点烦人：

  def add_words(words:Traversable[String], ignoreCase:Boolean=true,
                stopwords:Set[String]=Set[String]()) {
    ...
  }

在这种情况下，根本不需要 ignoreCase 和 stopwords 上的类型注释，它们只是增加了不必要的冗长。

感谢参与 Scala 开发的人员的任何评论。

Answer 1

1. Scala 已经添加了好东西很长一段时间了，但随着它的流行，它会变得越来越稳定。 2.8 之前的人们比现在的人们更有能力修改语言——这既是因为他们代表了更大比例的用户，也因为语言更加灵活。

   以您的删除问题为例。作为 2.0 用户，您将有比现在更大的机会完成一些事情。事实上，对兼容性的影响几乎可以保证这种情况不会再发生，除非 Java 领先。

2. 你来自脚本语言。脚本语言非常关心 I/O，因为那是它们的黄油和面包。对于 Scala 来说，任何重要的 I/O 都只是归入 Java 库——毕竟，这就是让 Scala 与 Java 兼容的意义所在。

   此外，您对 4662 的描述实际上是完全错误的。它根本没有被破坏，尽管行为的改变使得可以说不正确的代码再次工作。简而言之，这是 4662：

   val source = scala.io.Source.fromFile(new java.io.File("test1.file"))
   使用（来源）
   val 行 = source.getLines
   

   由于source是一个Iterator，一旦你使用它，它就消失了。这是一个巧合，您可以在调用 toString 后重用它，而不是内在保证。

3. 类型擦除并没有那么糟糕。事实上，如果它有太多阻碍，那就是糟糕设计的标志——你不应该检查某物的类型是什么，而是调用它的方法并让它自行处理。并不是说它有时不烦人，但也不是那么糟糕。唉，这是与 Java 无缝兼容的基本选择，而且是非常有意识地做出的。我不认为 Scala 能够走出困境。

   Ceylon 是承诺消除擦除并保持与 Java 兼容性的新语言之一。如果 Ceylon 做到了这一点，并且我坚定地站在怀疑者阵营中，那么 Scala 可能会效仿。

   此外，最近关于 Java 8 闭包的讨论表明了可能对擦除采取一些措施的可能性。如果事实证明这是真的，那么 Scala 也可以赚钱。

至于这个问题，我同意这些类型是可以推断的。然而，我不确定是否有人使用默认参数做某些事情——目前的优先事项在其他地方。

Answer 2

1. 是

2. 因为底层虚拟机抽象了对“外部”世界的任何访问，所以基本上可以选择要么附带编译代码，使 Scala 不独立于平台，要么使用诸如 java.io.File 完全损坏了。
   Java 7（仅仅 15 年之后）终于添加了一些可用的文件系统 API，据我所知，正在进行的 Scala IO 库已经将其作为目标。还有一点就是其他运行平台的支持。发布只有 JVM 实现的 Scala IO 库并不是一个好主意。基本上来说：几周前，Java 7 使得拥有一些像样的 IO 库成为可能。考虑到 Scala 在不久的将来不会放弃对 Java 6（和 5）的支持，因此不要指望标准库很快就会提供 IO。

3. 你用错了。但是，如果您认为“Scala 设计师会意识到这种愚蠢”，请随意创建您自己的语言，这会让一切变得更好。具体化的泛型很难与更高级的类型相结合。如果我必须选择，我每次都会选择 HKT 而不是具体化仿制药。

啊啊..对了。这些事情不是你的问题。回答您的实际问题：

这是可以做到的，但人们喜欢保持规则简单。所以可能不会。

Answer 3

我没有足够的代表权力将其添加为评论，因此我必须添加为答案。另外，这对于评论来说太长了。

关于主要问题，我同意可以推断具有默认值的输入参数的类型。我在他们的 Scala issues tracker 中执行了以下查询，但没有找到适用的功能请求。所以也许你可以在那里提交一份。

项目 = SI AND（摘要 ~“默认”AND 摘要 ~“值”）

1. 无评论
2. 无评论
3. 正如其他人指出的那样，具体化（即不是类型擦除）使得更高级的泛型更难以实现。这里直接引用了 Piessens、Moors、Odersky 的“Generics of a Higher Kind”第 6.1 节。

由于 Scala 在后端使用类型擦除，因此
更改仅限于类型检查器。显然，我们的扩展因此
对程序的运行时特性没有任何影响。
具有讽刺意味的是，由于类型擦除是其他限制的根源
Scala，这是实现类型构造函数的一个重要好处
多态性。

针对 .NET 平台的语言中的类似扩展面临着
更艰巨的挑战，因为虚拟机具有更丰富的类型概念
从而强制执行更严格的不变量。不幸的是，该模型
类型不包括更高级的类型。这样，才能保证充分
与该平台上其他语言的通用性的互操作性，
具有类型构造函数多态性的语言的编译器必须采用
部分擦除，以及代码专门化，以便
构造由以下结果产生的类型的必要表示
应用于参数的抽象类型构造函数。

您可以查看该论文以解释为什么高级泛型很重要。尽管 Scala 2.8 显然没有在新的集合库中广泛使用它们，但到目前为止 我发现不可能在一个没有高级类型的子类型化优雅方式（与 Scalaz 非子类型设计相比，我发现后者非常复杂）。

Daniel C. Sobral 关于您在答案下面的评论，我认为构造函数违反了 SOLID 中的 D 原则。 Urban Vagabon，应该利用工厂来实现控制反转，即好莱坞原则。另请参阅 Gilad Bracha 的博客“构造函数被认为是有害的”。

这并不是最完整或最好的答案，而是一些可能会添加到此知识库的部分想法。