Kotlin 1.4 和未来值得期待的地方

Kotlin 1.4 将于 2020 年春季推出，其开发团队在博客介绍了他们对 Kotlin 的愿景：“让 Kotlin 成为您所有工作的可靠伴侣，并是您执行任务的默认语言选择。”因此，开发团队将会让开发者在所有平台上都能使用 Kotlin。

据开发团队的介绍，Kotlin 1.4 将侧重于质量和性能。因为对现在的 Kotlin 来说，提高整体体验比添加新功能更加重要。此外，因为构建速度通常是用户最关心的问题，所以开发团队正在不断改进工具链以解决此问题。但是逐步改进跟不上生产代码库的自然增长：尽管开发团队加快了编译速度，但用户编写了更多的代码，使总体构建时间还不够短。为此，开发团队计划重新实现编译器以使其更快速。

新的编译器

新编译器实现的目标是变得更快速、统一 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 ）紧密合作。

新的语言功能：

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;  
    ... 
}