Kotlin 1.4 和未来值得期待的地方
在 KotlinConf 的主题演讲中，Andrey 强调了我们对 Kotlin 当前关注领域的战略观点，以及我们将明年发布的 Kotlin 1.4 计划。
在下面观看整个主题演讲
我们的愿景是让 Kotlin 成为您所有工作的可靠伴侣，并是您执行任务的默认语言选择。为此，我们将使它在所有平台上大放异彩。来自行业知名公司的多个案例研究表明，我们在这一方向上取得了很好的进展。
于 2020 年春季推出的 Kotlin 1.4 将会为 Kotlin 生态系统迈出新的一步。
专注于质量
最重要的是，Kotlin 1.4 将侧重于质量和性能。Kotlin 是一种已经开创了许多思想和方法的现代编程语言。我们将使它保持现代化并不断发展。此刻，对 Kotlin 来说，我们认为提高整体体验比添加新功能更加重要。这就是为什么 Kotlin 1.4 仅更改一些语言特性的原因，这些更改将在下文中进行详细说明。
我们在 IDE 支持 Kotlin 语言及性能方面上，已经取得了令人瞩目的成绩。与以前的版本相比，代码补全的速度已大大提高：
我们与 Gradle 团队一起提高了 Gradle 脚本的运行速度。Kotlin 1.3.60，Android Studio 中的 Gradle Import 大约是 Kotlin 1.3.10 的 2.5 倍，并且内存减少了约 75％：
此外，加载 build.gradle.kts 几乎不需要占用 CPU！而且，在开发模式下编译 Kotlin / Native 的速度与使用代码缓存的速度相比快了 2 倍。
我们知道构建速度通常是我们用户最关心的问题，我们正在不断改进工具链以解决此问题。但是逐步改进跟不上生产代码库的自然增长：尽管我们加快了编译速度，但用户编写了更多的代码，使总体构建时间还不够短。很明显的，我们需要重新实现编译器以使其更快速。
新的编译器
新编译器实现的目标是变得更快速、统一 Kotlin 支持的所有平台，并提供用于编译器扩展的 API。这将是一项多年的工作，不过我们已开始好一阵子了，因此新实现的某些部分将在 1.4 中发布，可让这个过程变得更加平顺。有些功能也已经发布了； 例如，如果您尝试了用于类型推理的新算法，它是新编译器的一部分。其他部分的处理方法相同。 也就是说，两种版本都将在一段时间内可用，旧版本和新版本都将处于实验模式； 当新的稳定后，它将成为默认版本。
新的前端（front-end）加速
我们期望新编译器提高的速度将来自新的前端实现。
为了提供一些背景信息，可以将编译想成吸收源文件并将其逐步转换为可执行代码的管道。此管道的第一步俗称为编译器的前端。它解析代码和命名、执行类型检查等。此编译器的这一部分也可以在 IDE 中使用，来高亮显示语法错误、导航到定义并搜索项目中的符号用法。这是 kotlinc 如今花费最多时间的步骤，因此我们希望使其更快。
当前的实现尚未完成，并且不会在 1.4 中到来。 但是，大多耗时的工作都是由它完成，因此我们可以预期提速的效果。我们的基准测试（编译 YouTrack 和 Kotlin 编译器本身）表明，新前端的速度约为现有前端快 4.5 倍。
统一的后端和可扩展性
在前端完成对代码的分析之后，后端将生成可执行文件。我们有三个后端：Kotlin / JVM，Kotlin / JS 和 Kotlin / Native。前两个以往是独立编写的，没有代码共享。当我们启动 Kotlin / Native 时，它是基于围绕 Kotlin 代码内部表示（internal representation）构建的新基础架构的，该功能具有与虚拟机中的字节码类似的功能。现在，我们将其他两个后端迁移到同一内部表示。因此，我们将共享许多后端逻辑并拥有统一的管道，以允许对所有目标仅执行一次大多数功能、优化和错误修复。
我们将逐步迁移到新的后端，可是在 1.4 中，默认情况下不太可能启用它们，但用户将能够选择明确使用它们。
通用的后端基础结构为跨平台编译器扩展打开了大门。可以在这管道中添加一些自定义处理和/或转换，这些处理和转换将自动适用于所有目标。在 1.4 中，我们不提供用于此类扩展的公开 API（该 API 稍后将被稳定），但我们正在与合作伙伴 （其中包括已经构建其编译器插件的 JetPack Compose ）紧密合作。
介绍 KLib：Kotlin 库格式
为了在 Kotlin 中构建跨平台库并将其发布以使客户可以依赖它，需要一种在任何平台上均能正常工作的发行格式。这就是为什么我们引入 KLib 的原因：KLib 是 Kotlin 跨平台的库格式。KLib 文件包含序列化的内部表示。您的代码可能会将其添加为依赖项，并且编译器后端将选择它并为给定平台生成可执行代码。与字节码的类比仍然存在：可以像 JVM 字节码一样分析和转换 KLib。对序列化内部表示进行的任何转换都会影响 KLib 将用于的任何平台。
实际上，Kotlin / Native 已经使用 KLibs 格式分发 Kotlin 本机库已有相当长的一段时间了，现在我们正在扩展该格式以支持其他后端和跨平台库。该格式将在 1.4 中进行实验，我们将在以后的版本中为其提供稳定的 ABI。
更多跨平台新闻
在 Android Studio 中运行 iOS 代码
我们正在开发适用于 Android Studio 的插件，该插件将能够在 iOS 设备和模拟器上运行、测试和调试 Kotlin 代码。该插件使用的是 IntelliJ 专有代码，因此将是封闭源代码。它不会带来对 Objective-C 或 Swift 的语言支持，并且某些操作（例如部署到 AppStore 可能需要运行 Xcode），但是您对 Kotlin 代码所做的任何操作都可以在安装了新插件的 Android Studio 中使用。我们希望在 2020 年发布此插件的预览。
Kotlin / Native 运行时改进
除了 Linux、Windows、macOS 和 iOS，Kotlin / Native 现在还可以在 watchOS 和 tvOS 上运行，因此几乎任何设备都可以运行 Kotlin。我们还致力于 Kotlin / Native 的运行时性能，以使 iOS Kotlin 程序运行得更快。
核心库
Kotlin 核心库可在所有平台上运行。其中包括处理所有基本类型和集合的 kotlin-stdlib 、 kotlinx.coroutines、 kotlinx.serialization 和 kotlinx.io 。在跨平台世界中确实需要对日期的支持，这就是我们正在努力的工作：实验性 Durations 已经添加到 stdlib 中，并且 DateTime 支持正在进行中。
Kotlin 库的另一个重要补充是 Flow，它是基于协同程序的 Reactive Streams 实现。Flow 非常适合处理数据流，并且利用了 Kotlin 的强大力量。除了符合人体工程学，Flow 还带来了额外的速度。在一些基准测试上，它的速度几乎是现有流行的 Reactive Streams 快 2 倍的实现。
对于库作者
由于创建新库对于 Kotlin 生态系统至关重要，因此我们将不断改善库作者的体验。新的库创作模式将以最适合稳定 API 的方式帮助您塑造代码。另外，我们将发布 Dokka 1.0 以支持所有平台的文档生成。
跨平台 web
跨平台共享代码对移动设备非常有用，而对 Web 客户端也非常有用：可以与服务器和 / 或移动应用程序共享很多内容。我们对 Kotlin / JS 工具的投资越来越多，现在可以进行非常快速的开发往返，从更改 Kotlin 代码到在浏览器中查看结果：
我们还改进了 JS 互操作，现在您可以将 NPM 依赖项附加到 Kotlin 项目，并且任何 .d.ts 类型定义都将由 Kotlin 工具链自动获取。新的基于内部表示的后端还将带来二进制大小的重大改进。编译后的 JS 文件可以变成其当前大小的一半。
新的语言功能：
Kotlin 1.4 将提供一些新的语言功能。
Kotlin 类的 SAM 转换
社区已要求我们引入对 Kotlin 类（ KT-7770 ）的 SAM 转换的支持。如果仅将一个抽象方法的接口或类预计作为参数，则将 lambda 作为参数传递时，将应用 SAM 转换。然后，编译器自动将 lambda 转换为实现抽象成员函数的类的实例。
SAM 转换当前仅适用于 Java 接口和抽象类。该设计背后的最初想法是针对此类用例明确使用函数类型。然而，事实证明，函数类型和类型别名并不能涵盖所有用例，开发者常常不得不仅在 Java 中保留接口才能对其进行 SAM 转换。
与 Java 不同，Kotlin 不允许使用一种抽象方法对每个接口进行 SAM 转换。我们认为，使接口适用于 SAM 转换的意图应该明确。因此，要定义 SAM 接口，您需要使用 fun 关键字标记一个接口，以强调它可以用作功能性接口：
fun interface Action {
fun run()
}
fun runAction(a: Action) = a.run()
fun main() {
runAction {
println("Hello, KotlinConf!")
}
}
请注意，仅在新的类型推断算法中支持传递 lambda 而不是 fun 接口。
混合命名和位置参数
Kotlin 禁止将带有显式名称的参数（“命名”）和不带名称的常规参数（“位置”）混合使用，除非仅将命名参数放在所有位置参数之后。但是，在一种情况下，这确实很烦人：当所有参数都保持在正确的位置而您想为中间的一个参数指定名称时。Kotlin 1.4 将解决此问题，因此您将能够编写如下代码：
fun f(a: Int, b: Int, c: Int) {}
fun main() {
f(1, b = 2, 3)
}
优化的委托属性
我们将改进 lazy 属性和其他一些委托属性的编译方式。
通常，委托属性可以访问相应的 KProperty 反射对象。例如，当使用 Delegates.observable 时，可以显示有关已修改属性的信息：
import kotlin.properties.Delegates
class MyClass {
var myProp: String by Delegates.observable("<no name>") {
kProperty, oldValue, newValue ->
println("${kProperty.name}: $oldValue -> $newValue")
}
}
fun main() {
val user = MyClass()
user.myProp = "first"
user.myProp = "second"
}
为了使之成为可能，Kotlin 编译器会生成一个附加的语法成员属性，即一个存储所有 KProperty 对象的数组，这些对象表示在类内部使用的委托属性：
>>> javap MyClass
public final class MyClass {
static final kotlin.reflect.KProperty[] $$delegatedProperties;
...
}
但是，某些委托属性不会以任何方式使用 KProperty。对于他们来说，在 $$delegatedProperties 中生成对象是次优的。Kotlin 1.4 版本将优化这种情况。如果委托属性运算符是 inline，并且未使用 KProperty 参数，则不会生成相应的反射对象。最出色的示例是 lazy 属性。lazy 属性的 getValue 实现是 inline，并且不使用 KProperty 参数：
inline operator fun <T> Lazy<T>.getValue(thisRef: Any?, property: KProperty<*>): T = value
从 Kotlin 1.4 开始，当您定义 lazy属性时，将不会生成相应的 KProperty实例。如果您在类中使用的唯一委托属性是 lazy属性（以及符合此优化的其他属性），则不会为类生成整个 $$delegatedProperties 数组：
class MyOtherClass {
val lazyProp by lazy { 42 }
}
>>> javap MyOtherClass
public final class MyOtherClass {
// no longer generated:
static final kotlin.reflect.KProperty[] $$delegatedProperties;
...
}
尾随逗号
这个微小的语法变化原来是非常方便的！您可以在参数列表中的最后一个参数之后放置一个附加的尾随逗号。然后，您可以交换行或添加新参数，而不必添加或删除丢失的逗号。
其他主要变化
Kotlin 1.3.40 中引入了的有用的 typeof 函数将变得稳定并在所有平台上得到支持。
1.3.60 版本博客文章中已经描述了使您可以在 when 内启用 break 和 continue 的功能。
谢谢！
非常感谢所有尝试过 Kotlin EAP 和实验性功能并提供反馈的人。我们正在与您一起开发 Kotlin 语言，并根据您的宝贵意见做出许多设计决策。与社区保持这种快速有效的反馈循环对确保 Kotlin 成为最佳状态非常重要！
我们非常感谢社区中所有与 Kotlin 共同创造了许多令人惊奇的事物的成员。让我们一起继续 Kotlin！
请注意，IntelliJ IDEA 和 Android Studio 中的 Kotlin 插件会收集您使用其功能的匿名统计信息。我们希望您选择分享这些统计信息，因为这可以帮助我们了解有效的功能、造成麻烦的问题以及我们应关注的改进重点。
Subscribe to JetBrains Blog updates
