[译]记一次Kotlin官方文档翻译的PR(内联类)

本文主要是介绍[译]记一次Kotlin官方文档翻译的PR(内联类)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在这里插入图片描述
简述: 这几天突然没更新文章了，可能有的小伙伴认为寒冬将至，是不是认为我跑路了(哈哈，确实不是哈，这几天感冒挺厉害的，再加上前几天连续熬夜写文章，感觉快扛不住了，所以暂时休息停更了一周。这不这篇内联类官网文档的翻译，已经拖了很多天，今天总算给中文社区的大佬提了PR)。

翻译说明:

原标题: inline-class

原文地址: Kotlin官网

译文地址: Kotlin中文站-内联类

内联类

内联类仅在 Kotlin 1.3 之后版本可用，目前还是实验性的。关于详情请参见下文

有时候，业务逻辑需要围绕某种类型创建包装器。然而，由于额外的堆内存分配问题，它会引入运行时的性能开销。此外，如果被包装的类型是原生类型，性能的损失是很糟糕的，因为原生类型通常在运行时就进行了大量优化，然而他们的包装器却没有得到任何特殊的处理。

为了解决这类问题，Kotlin引入了一种被称为 内联类 的特殊类，它通过在类的前面定义一个 inline 修饰符来声明：

inline class Password(val value: String)

内联类必须含有唯一的一个属性在主构造函数中初始化。在运行时，将使用这个唯一属性来表示内联类的实例 (关于运行时的内部表达请参阅下文)：

// 不存在 'Password' 类的真实实例对象
// 在运行时，'securePassword' 仅仅包含 'String'
val securePassword = Password("Don't try this in production")

这就是内联类的主要特性，它灵感来源于 “inline” 这个名称：类的数据被 “内联”到该类使用的地方(类似于内联函数中的代码被内联到该函数调用的地方)。

成员

内联类支持普通类中的一些功能。特别是，内联类可以声明属性与函数:

inline class Name(val s: String) {val length: Intget() = s.lengthfun greet() {println("Hello, $s")}
}    fun main() {val name = Name("Kotlin")name.greet() // `greet` 方法会作为一个静态方法被调用println(name.length) // 属性的 get 方法会作为一个静态方法被调用
}

然而，内联类的成员也有一些限制:

内联类不能含有 init 代码块
内联类不能含有 inner 类
内联类不能含有幕后字段
- 因此，内联类只能含有简单的计算属性(不能含有延迟初始化/委托属性)

继承

内联类允许去继承接口

interface Printable {fun prettyPrint(): String
}inline class Name(val s: String) : Printable {override fun prettyPrint(): String = "Let's $s!"
}    fun main() {val name = Name("Kotlin")println(name.prettyPrint()) // 仍然会作为一个静态方法被调用
}

禁止内联类参与到类的继承关系结构中。这就意味着内联类不能继承其他的类而且必须是 final。

表示方式

在生成的代码中，Kotlin编译器为每个内联类保留一个包装器。内联类的实例可以在运行时表示为包装器或者基础类型。这就类似于 Int 可以表示为原生类型 int 或者包装器 Integer。

为了生成性能最优的代码，Kotlin 编译更倾向于使用基础类型而不是包装器。然而，有时候使用包装器是必要的。一般来说，只要将内联类用作另一种类型，它们就会被装箱。

interface Iinline class Foo(val i: Int) : Ifun asInline(f: Foo) {}
fun <T> asGeneric(x: T) {}
fun asInterface(i: I) {}
fun asNullable(i: Foo?) {}fun <T> id(x: T): T = xfun main() {val f = Foo(42) asInline(f)    // 拆箱操作: 用作 Foo 本身asGeneric(f)   // 装箱操作: 用作泛型类型 TasInterface(f) // 装箱操作: 用作类型 IasNullable(f)  // 装箱操作: 用作不同于 Foo 的可空类型 Foo?// 在下面这里例子中，'f' 首先会被装箱(当它作为参数传递给 'id' 函数时)然后又被拆箱(当它从'id'函数中被返回时)// 最后， 'c' 中就包含了被拆箱后的内部表达(也就是 '42')， 和 'f' 一样 val c = id(f)  
}

因为内联类既可以表示为基础类型有可以表示为包装器，引用相等对于内联类而言毫无意义，因此这也是被禁止的。

名字修饰

由于内联类被编译为其基础类型，因此可能会导致各种模糊的错误，例如意想不到的平台签名冲突：

inline class UInt(val x: Int)// 在JVM平台上被表示为'public final void compute(int x)'
fun compute(x: Int) { }// 同理，在JVM平台上也被表示为'public final void compute(int x)'!
fun compute(x: UInt) { }

为了缓解这种问题，一般会通过在函数名后面拼接一些稳定的哈希码来重命名函数。因此, fun compute(x: UInt) 将会被表示为 public final void compute-<hashcode>(int x), 以此来解决冲突的问题。

请注意在Java中 - 是一个 无效的 符号，也就是说在Java中不能调用使用内联类作为形参的函数。

内联类与类型别名

初看起来，内联类似乎与类型别名非常相似。实际上，两者似乎都引入了一种新的类型，并且都在运行时表示为基础类型。

然而，关键的区别在于类型别名与其基础类型(以及具有相同基础类型的其他类型别名)是 赋值兼容 的，而内联类却不是这样。

换句话说，内联类引入了一个真实的新类型，与类型别名正好相反，类型别名仅仅是为现有的类型取了个新的替代名称(别名)：

typealias NameTypeAlias = String
inline class NameInlineClass(val s: String)fun acceptString(s: String) {}
fun acceptNameTypeAlias(n: NameTypeAlias) {}
fun acceptNameInlineClass(p: NameInlineClass) {}fun main() {val nameAlias: NameTypeAlias = ""val nameInlineClass: NameInlineClass = NameInlineClass("")val string: String = ""acceptString(nameAlias) // 正确: 传递别名类型的实参替代函数中基础类型的形参acceptString(nameInlineClass) // 错误: 不能传递内联类的实参替代函数中基础类型的形参// And vice versa:acceptNameTypeAlias("") // 正确: 传递基础类型的实参替代函数中别名类型的形参acceptNameInlineClass("") // 错误: 不能传递基础类型的实参替代函数中内联类类型的形参
}

内联类的实验性状态

内联类的设计目前是实验性的，这就是说此特性是正在 快速变化的，并且不保证其兼容性。在 Kotlin 1.3+ 中使用内联类时，将会得到一个警告，来表明此特性还是实验性的。

要想移除警告，你必须通过对 kotlinc 指定 -XXLanguage:+InlineClasses参数来选择使用该实验性的特性。

在Gradle中启用内联类:


compileKotlin {kotlinOptions.freeCompilerArgs += ["-XXLanguage:+InlineClasses"]
}

关于详细信息，请参见编译器选项。关于多平台项目的设置，请参见使用Gradle构建多平台项目章节。

在Maven中启用内联类

<configuration><args><arg>-XXLanguage:+InlineClasses</arg> </args>
</configuration>

关于详细信息，请参见指定编译器选项。

进一步讨论

关于其他技术详细信息和讨论，请参见内联类的语言提议

译者有话说

为什么要翻译官方文档，其实只想向大家传递一个信息: Kotlin的官方文档确实不错，也许学会看官方文档才能让你走得更快和更远。我们都知道学习一个新的技术，最好的方式就是看官方文档。 为什么说Kotlin官方文档不错，以此次内联类举例，是不是还记得之前我翻译几篇国外大佬有关kotlin内联类的文章，可以说把内联类研究得很全面了，比如内联类自动装箱和性能优化，内联类与typealias类型别名的区别等等，可以看下其实这些官网都有提到。所以国外大佬无非也是在官网基础上对某个问题进行更深入挖掘和探索。所以多看技术官方文档，能让你对某项技术了解的更加全面。

问题来了，可能很多人都厌倦看英文了，所以这次给大家安利一波Kotlin官方认准的Kotlin中文站、Kotlin中文博客、Kotlin中文社区。