Kotlin 1.4の変更点

※ソース記事は[こちら](https://kotlinlang.org/docs/whatsnew14.html)
※Kotlin/JSやKotlin/Nativeについては個人的に使っていないので、割愛します。

Kotlin1.4では、すべての構成要素の中で、品質と性能にフォーカスした数多くの改善が出荷されている。以下に、Kotlin1.4.0での最も重要な変更点のリストがある。

# 言語の特徴と改善
Koltin 1.4.0には様々な異なる言語の特徴と改善が搭載されている。
- KotlinインターフェイスのためのSAM構文
- ライブラリ開発者のための明示的APIモード
- 名前と位置の引数の混在
- 末尾のカンマ
- 関数参照の改善

## KotlinインターフェイスのためのSAM構文
Kotlin1.4より前は、SAM(単一の抽象メソッド)構文は、KotlinからはJavaのメソッドとJavaのインターフェイスと連携するときのみ、適用することができた。今からは、Kotlinインターフェイスも同様にSAM規約を使うことができる。そうするには、Kotlinインターフェイスを
fun修飾子で明示的に関数としてマークする。
SAM構文は唯一の抽象メソッドを持つインターフェイスが引数として予想されているときに、ラムダを引数として渡す場合に適用される。この場合、コンパイラが自動で、ラムダを抽象メンバを実装したクラスのインスタンスに変換する。
```Kotlin
fun interface IntPredicate {
    fun accept(i: Int): Boolean
}

val isEven = IntPredicate { it % 2 == 0 }

fun main() { 
    println("Is 7 even? - ${isEven.accept(7)}")
}
```
## ライブラリ開発者のための明示的APIモード
Kotlinコンパイラは明示的APIモードをライブラリ開発者のために提供する。このモードでは、コンパイラは追加のチェックを実施して、ライブラリのAPIをよりクリアに、より一貫性のあるように手助けする。それはライブラリの公開APIにさらされた宣言に、次の必須チェックを追加する。
- もしデフォルトの修飾子が公開APIにさらされている場合、可視性修飾子の宣言が必要になる。これは意図せず公開APIにさらされることを無くす手助けになる。
- 公開APIにさらされているプロパティや関数は、明示的な型の指定が必要になる。これはAPIの使用者が自分の使うAPIメンバの型を意識することを保証する。
設定に応じて、これらの明示的APIは、エラー(strictモード)か、警告(warningモード)を生成することができる。ある種の宣言は、読みやすさと常識のためにチェックが除外されている。
 - プライマリコンストラクタ
 - dataクラスのプロパティ
 - getterとsetterのプロパティ
 - overrideメソッド

明示的APIモードは、モジュールの本番ソースにのみ、分析を行う。
明示的APIモードでモジュールをコンパイルするには、Gradleビルドスクリプトに以下の行を追加する。
```Kotlin
kotlin {
    // for strict mode
    explicitApi()
    // or
    explicitApi = ExplicitApiMode.Strict

    // for warning mode
    explicitApiWarning()
    // or
    explicitApi = ExplicitApiMode.Warning
}
```
コマンドラインコンパイラを使用するときは、`-Xexplicit-api`コンパイラオプションを追加することで、明示的APIモードに切り替わる。
```Kotlin
-Xexplicit-api={strict|warning}
```
## 名前と位置の引数の混在
Kotin 1.3では、名前つき引数で関数を呼ぶときは、最初の名前付き引数の前に、すべての引数を名前無し(位置引数)で配置しなければならなかった。例として、`f(1, y = 2)`は呼び出せるが、`f(x = 1, 2)`は呼び出せなかった。
このことはすべての引数が正しい位置にあるが、中間の一つの引数を名前付き引数を指定したいときに非常に悩ましかった。それはboolean属性や、null値が含まれていることを明確にするために特に役に立つ。
Kotlin 1.4では、そのような制限はない。位置引数の中間に名前付き引数を指定することができる。さらに正しい順序を維持する限り、位置と名前引数をどのようにでも混在することができる。
```Kotlin
fun reformat(
    str: String,
    uppercaseFirstLetter: Boolean = true,
    wordSeparator: Char = ' '
) {
    // ...
}

// 中間の名前付き引数での関数呼び出し
reformat("This is a String!", uppercaseFirstLetter = false , '-')
```
## 末尾のカンマ
Kotlin 1.4では引数やパラメータリストやwhenエントリ、分割宣言の構成要素のような、列挙の中の末尾のカンマを追加することができる。末尾のカンマにより、カンマを追加したり削除したりせずに新規項目を追加したり、順番を変えることができる。
これは特に、パラメータあるいは値のために複数行の文法を使うなら、特に役に立つ。末尾のカンマを追加した後で、簡単にパラメータや値を行入れ替えすることができる。
```Kotlin
fun reformat(
    str: String,
    uppercaseFirstLetter: Boolean = true,
    wordSeparator: Character = ' ', // 末尾のカンマ
) {
    // ...
}
```
```Kotlin
val colors = listOf(
    "red",
    "green",
    "blue", // 末尾のカンマ
)
```
## 関数参照の改善
 Kotlin 1.4は関数参照を使うためのより多くのケースをサポートしている。
 - デフォルト引数を持つ関数への参照
 - Unitを戻す関数内の関数参照
 - 関数内の引数の数に基づいて適用する参照
 - 関数参照についてのSuspend構文

###  デフォルト引数を持つ関数への参照
今ではデフォルト引数を持つ関数への関数参照を使うことができる。もし引数を持たないfoo関数への関数参照の場合、デフォルト値の0が使われる。
```Kotlin
fun foo(i: Int = 0): String = "$i!"

fun apply(func: () -> String): String = func()

fun main() {
    println(apply(::foo)) // 0!
}
```
以前は、デフォルト引数を使うためにapply関数のオーバーロードを追加で書く必要があった。
```Kotlin
// some new overload
fun applyInt(func: (Int) -> String): String = func(0)
```

### Unitを戻す関数内の関数参照
Kotlin 1.4では、Unitを戻り値にする関数内で、関数参照を使うことができる。Kotlin 1.4より前は、この場合、ラムダ引数を使うしかなかった。今ではラムダ引数と関数参照両方使うことができる。
```Kotlin
fun foo(f: () -> Unit) { }
fun returnsInt(): Int = 42

fun main() {
    foo { returnsInt() } // 1.4より前はこれが可能な唯一の方法
    foo(::returnsInt) // Kotlin 1.4からはこれも使える
}
```
### 関数内の引数の数に基づいて適用する参照
今では可変長の引数(vararg)を渡す関数への関数参照を適用することができる。引数のリストの最後が同じ型であるどんな数のパラメータも渡すことができる。
```Kotlin
fun foo(x: Int, vararg y: String) {}

fun use0(f: (Int) -> Unit) {}
fun use1(f: (Int, String) -> Unit) {}
fun use2(f: (Int, String, String) -> Unit) {}

fun test() {
    use0(::foo)
    use1(::foo)
    use2(::foo)
}
```
### 関数参照についてのSuspend構文
ラムダに関するsuspend構文に加えて、Kotlinは今では1.4.0から始まる関数参照に関するsuspend構文をサポートしている。
```Kotlin
fun call() {}
fun takeSuspend(f: suspend () -> Unit) {}

fun test() {
    takeSuspend { call() } // 1.4より前はOK
    takeSuspend(::call) // Kotlin 1.4ではこれも動く
}
```

## ループに含まれるwhen式の内部でのbreakとcontinueの使用
Kotlin 1.3では、ループに含まれるwhen式の内部でbreakとcontinueを無制限に使うことができなかった。これらのキーワードはwhen式のフォールスルーの挙動の可能性のため、予約されていることが原因だった。
このため、もしループ内のwhen式の内側でbreakとcontinueを使いたいなら、少々面倒だがラベル付けをする必要があった。
```Kotlin
fun test(xs: List<Int>) {
    LOOP@for (x in xs) {
        when (x) {
            2 -> continue@LOOP
            17 -> break@LOOP
            else -> println(x)
        }
    }
}
```
Kotlin 1.4ではループ内のwhen式の内側でbreakとcontinueをラベル無しで使うことができる。これらは期待通り、最も近い囲っているループを終了するか、その次のステップに進む挙動をする。
```kotlin
fun test(xs: List<Int>) {
    for (x in xs) {
        when (x) {
            2 -> continue
            17 -> break
            else -> println(x)
        }
    }
}
```
whenの内側のフォールスルーの挙動については、さらに先の設計の対象である。
# IDEの新しいツール(※割愛)
# 新しいコンパイラ
新しいKotlinのコンパイラは本当に速くなっている。すべてのサポート対象のプラットフォームを統一し、拡張のためのAPIを提供していく。それは長期にわたるプロジェクトであり、Kotlin 1.4でいくつかのステップを完了した。
- 新しく強力な型推論アルゴリズムがデフォルトで有効
- 新しいVMとJSのバックエンド。それらは安定化すればデフォルトとする。
## 新しく強力な型推論アルゴリズム
Kotlin 1.4は、 新しく強力な型推論アルゴリズムを使用する。この新しいアルゴリズムはKotlin 1.3でコンパイラオプションですでに試すことができたが、今ではデフォルトとして使われる。[YouTrack](https://youtrack.jetbrains.com/issues/KT?q=Tag:%20fixed-in-new-inference%20)の中で、新しいアルゴリズムで修正された全リストを見ることができる。ここでは最も注目すべき改善のいくつかを見ていく。
- より多くのケースでの型推論
- ラムダの最後の式のためのスマートキャスト
- 関数参照のためのスマートキャスト
- delegateプロパティのためのより良い推論
- 異なる引数を持つJavaインターフェイスのためのSAM構文
- Kotlin内でのJavaのSAMインターフェイス

### より多くのケースでの型推論
新しい推論アルゴリズムは、古いアルゴリズムが明示的に指定する必要があった、多くのケースのための推論をする。例えば、次の例ではラムダのパラメータ`it`の型は正しく`String?`と推論する。
```Kotlin 
val rulesMap: Map<String, (String?) -> Boolean> = mapOf(
    "weak" to { it != null },
    "medium" to { !it.isNullOrBlank() },
    "strong" to { it != null && "^[a-zA-Z0-9]+$".toRegex().matches(it) }
)
```
Kotlin 1.3で動かすためには、明示的にラムダパラメータを導入し、`to`を明示的なジェネリクス引数を持つ`Pair`に置き換える必要があった。
### ラムダの最後の式のためのスマートキャスト
Kotlin 1.3では、ラムダの最後の式は、期待する型を指定しない限り、スマートキャストされなかった。したがって次の例では、Kotlin 1.3は`result`変数の型として`String?`を推論する。
```Kotlin
val result = run {
    var str = currentValue()
    if (str == null) {
        str = "test"
    }
    str // the Kotlin compiler knows that str is not null here
}
// The type of 'result' is String? in Kotlin 1.3 and String in Kotlin 1.4
```
Kotlin 1.4では、新しい推論アルゴリズムにより、ラムダの最後の式はスマートキャストされ、この新しくより正確な型は結果として生じるラムダ型の推論に使われる。したがって`result`変数の型は`String`になる。
Kotlin 1.3では、このケースを動かすためには、明示的なキャスト(`!!`か`as String`のような型キャスト)の追加が度々必要だったが、今ではこれらのキャストは不要になった。
### 関数参照のためのスマートキャスト
Kotlin 1.3では、スマートキャストの型のメンバ参照にアクセスすることができなかった。今ではKotlin 1.4で可能。
```Kotlin
import kotlin.reflect.KFunction

sealed class Animal
class Cat : Animal() {
    fun meow() {
        println("meow")
    }
}

class Dog : Animal() {
    fun woof() {
        println("woof")
    }
}
fun perform(animal: Animal) {
    val kFunction: KFunction<*> = when (animal) {
        is Cat -> animal::meow
        is Dog -> animal::woof
    }
    kFunction.call()
}
```
animal変数が特定の型である`Cat`と`Dog`にスマートキャストされた後であれば、`animal::meow`と`animal::woof`の異なるメンバ参照を使うことができる。型チェックの後はサブタイプに応じたメンバ参照へアクセスできる。
### delegateプロパティのためのより良い推論
delegateプロパティの型は`by`キーワードに続くdelegate表記を解析している間は、考慮されていなかった。例えば、次のコードは以前はコンパイルできなかったが、現在はコンパイラは`old`と`new`パラメータを`String?`として正しく推論する。
```Kotlin
import kotlin.properties.Delegates

fun main() {
    var prop: String? by Delegates.observable(null) { p, old, new ->
        println("$old → $new")
    }
    prop = "abc" // null -> abc
    prop = "xyz" // abc -> xyz
}
```
### 異なる引数を持つJavaインターフェイスのためのSAM構文
Kotlinは最初からJavaのインターフェイスのためのSAM構文をサポートしていたが、サポートされない一つのケースがあった。それは既存のJavaライブラリと連携するときにときどき迷惑だった。もし2つのSAMインターフェイスを取るJavaのメソッドをパラメータとして呼び出すなら、両方の引数はラムダか、通常のオブジェクトである必要があった。一つの引数はラムダで、もう一つはオブジェクトとして渡すことはできなかった。
新しいアルゴリズムは、この問題を修正し、どんなケースでもSAMインターフェイスの代わりにラムダを渡すことができ、それは当然期待通りに動作する方法です。
```Kotlin
// FILE: A.java
public class A {
    public static void foo(Runnable r1, Runnable r2) {}
}
```
``` Kotlin
// FILE: test.kt
fun test(r1: Runnable) {
    A.foo(r1) {}  // Works in Kotlin 1.4
}
```
### Kotlin内でのJavaのSAMインターフェイス
Kotlin 1.4では、KotlinでJavaのSAMインターフェイスを使うことができ、それらに対してSAM構文を適用することができる。
```Kotlin
import java.lang.Runnable

fun foo(r: Runnable) {}

fun test() {
    foo { } // OK
}
```
Kotlin 1.3ではSAM構文を実行するためには、上記の`foo`関数をJavaコードで宣言しなければならなかった。
## 統一されたバックエンドと拡張性
Kotlinには、実行モジュールを生成する３つのバックエンドがある。Kotlin/JVM、Kotlin/JS、KotlinNativeである。Kotlin/JVMとKotlin/JSはお互い独立して開発されたため、あまりコードを共有していない。Kotlin/NativeはKotlinコードのための中間表現(IR)を中心に建てられた新しい基礎をもとにしている。
現在、Kotlin/JVMとKotlin/JSは同じ中間表現に移行している。結果として３つすべてのバックエンドは多くのコードを共有し、統一した経路を持つ。このことはすべてのプラットフォームにとって、一度だけで多くの特徴、最適化、バグフィックスを実装することに役立つ。両方の新しい中間表現のバックエンドはAlpha状態である。
共通のバックエンド基盤はマルチプラットフォームのコンパイラーの拡張を可能にする。経路にプラグインし、すべてのプラットフォームで自動で動作するカスタム処理と変換を追加することが可能になるだろう。
我々は現在アルファ版である、新しいJVMの中間表現とJSの中間表現のバックエンドを使ってフィードバックを共有してもらうことをお勧めしている。
# Kotlin/JVM
Kotlin 1.4は次のような多くのJVM固有の改善を含んでいる。
- 新しいJVM中間表現のバックエンド
- インターフェイスのデフォルトメソッドを生成する新しいモード
- nullチェックのための統一した例外
- JVMバイトコード内の型アノテーション
##  新しいJVM中間表現のバックエンド
Kotlin JSと並んで、Kotlin/JVMは統一した中間表現バックエンドへ移行しており、それは多くの特徴とバグフィックスをすべてのプラットフォームのために一度に実装することを可能にする。このことは、すべてのプラットフォームで動作するマルチプラットフォームの拡張を作ることにより、恩恵を受けることもできるだろう。
Kotlin 1.4はまだそのような拡張のための公開APIを提供していないが、Jetpack Composeに含まれるパートナーと綿密に協力しており、彼らはすでに私たちの新しいバックエンドを使ってコンパイラの拡張を構築している。
私たちは新しいKotlin/JVMのバックエンド、これは現在Alphaであり、を試し、issue trackerで何かの問題や要望を挙げることを勧めている。これはより早くコンパイラの経路を統合し、KotlinコミュニティにJetpack Composeのようなコンパイラ拡張をもたらすことに役立つ。
新しいJVMの中間表現バックエンドを有効化するには、追加のコンパイラオプションをGradleビルドスクリプトに指定する。
```Kotlin
kotlinOptions.useIR = true
```
:::note warn
もしJetpack Composeを有効にするなら、自動で新しいJVMバックエンドが許可されるので、`kotlinOptions`内でコンパイラオプションを指定する必要はない。
:::

コマンドラインコンパイラを使用しているときは、`Xuse-ir`コンパイラオプションを追加する。

:::note warn
新しいバックエンドを有効にする場合のみ、新しいJVMの中間表現バックエンドによりコードがコンパイルされたコードを使うことができる。そうでない場合、エラーとなる。このことを考慮すると、ライブラリ開発者は、本番で新しいバックエンドに切り替えることはお勧めしない。
:::

## インターフェイスのデフォルトメソッドを生成する新しいモード
KotlinコードをJVM 1.8以上をターゲットにコンパイルしているとき、Kotlinインターフェイスの抽象でないメソッドをJavaのデフォルトメソッドにコンパイルできた。この目的のため、そのようなメソッドをマークするための`@JvmDefault`アノテーションと、そのアノテーションを処理するための`-Xjvm-default`コンパイラオプションを含むメカニズムがあった。
1.4.0では、デフォルトメソッドを生成するための新しいモードが追加されている。`-Xjvm-default=all`は、Kotlinインターフェイスのすべての抽象でないメソッドを`default`Javaメソッドでコンパイルする。`default`無しでコンパイルされたインターフェイスを使うコードとの互換性のため、`all-compatibility`モードも追加された。
Java相互運用におけるデフォルトメソッドについて、詳細については[相互運用の文書](https://kotlinlang.org/docs/java-to-kotlin-interop.html#default-methods-in-interfaces)と[このブログ投稿](https://blog.jetbrains.com/kotlin/2020/07/kotlin-1-4-m3-generating-default-methods-in-interfaces/)を見てほしい。
## nullチェックのための統一した例外
Kotlin 1.4から、すべての実行時nullチェックは`KotlinNullPointerException`と`IllegalStateException`と`IllegalArgumentException`と`TypeCastException`の代わりに`java.lang.NullPointerException`をスローする。これは`!!`演算子や、メソッド構文での引数のnullチェックや、プラットフォーム型表現のnullチェックや、非null型での`as`演算子に当てはまる。これは`lateinit`のnullチェックと`checkNotNull`や`requireNotNull`のような明示的なライブラリ関数には当てはまらない。
この変更はKotlinコンパイラか、Android R8オプティマイザのような何種類ものバイトコード処理ツールによって、実行されるnullチェックの最適化の可能性を増やす。
注意すべきは、開発者の視点からは物事はそれほど変わらない：Kotlinコードは以前と同じエラーメッセージを持つ例外をスローするためである。例外の型は変わるが、情報は変わらず渡される。
## JVMバイトコード内の型アノテーション
Kotlinは今では(ターゲットバージョン1.8以上の)JVMバイトコードで型アノテーションが生成するため、実行時のJavaリフレクションでそれらは利用できる。バイトコードに型アノテーションを発行するには、以下のステップに従うこと。
1. 宣言したアノテーションが適切なアノテーションターゲット(Javaの`ElementType.TYPE_USE`かKotlinの`AnnotationTarget.TYPE`)とリテンション(`AnnotationRetention.RUNTIME`)を持つこととを確認する。
1. アノテーション宣言クラスがターゲットバージョン1.8以上でコンパイルすること。コンパイラオプションで`-jvm-target=1.8`を指定することで可能。
1. アノテーションを使うコードをターゲットバージョン1.8以上でコンパイル(`-jvm-target=1.8`)することと、コンパイラオプションに`-Xemit-jvm-type-annotation`を追加すること。
注意すべきは、標準ライブラリからの型アノテーションは、現在はバイトコードには発行されていない。なぜなら標準ライブラリはターゲットバージョン1.6でコンパイルされているからだ。
今のところ、次のような基本的なケースのみがサポートされている。
- メソッドパラメータとメソッドの戻り値とプロパティ型の型アノテーション
- 型引数の不変の射影、例えば`Smith<@Ann Foo>`や`Array<@Ann Foo>`
次の例えは、`String`型についた`@Foo`アノテーションはバイトコードに発行され、その後ライブラリコードに使うことができる。
```Kotlin
@Target(AnnotationTarget.TYPE)
annotation class Foo

class A {
    fun foo(): @Foo String = "OK"
}
```
# Gradleプロジェクトの改善
Kotlin Multiplatform、Kotlin/JVM、Kotlin/JS固有のGradleプロジェクトの特徴や改善を別にして、すべてのKotlin Gradleプロジェクトに当てはまる変更がいくつか存在する。
- デフォルトで標準ライブラリへの依存関係が追加される
- KotlinプロジェクトはGradleの最新バージョンが必要
- IDEでのKotlin Gradle DSLのための改善
## デフォルトで標準ライブラリへの依存関係が追加される
mulitplatformを含め、どのGradleプロジェクトでも、もはや`stdlib`ライブラリへの依存性を宣言する必要はない。
自動的に追加された標準ライブラリは同一のバージョニングのため、Kotlin Gradleプラグインと同じバージョンである。
プラットフォーム固有のソース群のため、対応するプラットフォーム固有のライブラリの異なるものが使われる。共通の標準ライブラリがその他残りに追加されるとしても。Kotlin Gradleプラグインは、Gradleビルドスクリプトの`kotlinOptions.jvmTarget`コンパイラオプションに依存した、適切なJava標準ライブラリを選択する。
## Kotlinプロジェクトのための最低Gradleバージョン
Kotlinプロジェクトの特徴を楽しむため、Gradleを最新バージョンに更新すること。MultiplatformプロジェクトはGradle 6.0以上を必要とし、他のKotlinプロジェクトはGradle 5.4以上と連携する。
## IDEでの改善された*.gradle.ktsのサポート
1.4.0ではGradle Kotlin DSLスクリプト(*.gradle.kts)のためIDEサポートが引き続き改善されている。
- より良いパフォーマンスのための明示的なスクリプト構成のローディング。以前はビルドスクリプトへの変更は、バックグラウンドで自動的にロードされていた。パフォーマンスを改善するため、1.4.0ではビルドスクリプト構成の自動ローディングは無効にされた。今では、明示的に適用するときのみ、IDEで変更をロードする。
バージョン6.0より前のGradleでは、エディタで**構成のロード**をクリックすることでスクリプト構成を手動でロードする必要がある。
Gradle 6.0以上とIntelliJ IDEA 2020.1では、もう一つのアクション**スクリプト構成のロード**が追加されている。これはプロジェクト全体を更新することなく、スクリプト構成の変更をロードする。これはプロジェクト全体を再インポートするよりもかなり短い時間で済む。
<img src = "https://kotlinlang.org/docs/images/gradle-kts.png">

新しく作られたプロジェクトか、新しいKotlinプラグインでプロジェクトを始めて開くときも、**スクリプト構成のロード**をするべきである。
Gradle 6.0以上では、以前の実装では、スクリプトを個々にロードしていたのに対して、今では一度にすべてのスクリプトのロードができるようになっている。それぞれの要求は実行時にGradle構成フェーズが必要になるので、このことは大きなGradleプロジェクトでリソースの節約になるだろう。
現在、このようなローディングは`build.gradle.kts`と`setting.grdle.kts`ファイルに限定されている。`init.gradle.kts`や提供されている[スクリプトプラグイン](https://docs.gradle.org/current/userguide/plugins.html#sec:script_plugins)を強調するには、古いメカニズム(スタンドアロンスクリプトとして追加)を使用すること。そのスクリプトのための構成は、必要となった時に個別にロードされる。そのようなスクリプトのために自動リロードを有効するにすることもできる。
<img src="https://kotlinlang.org/docs/images/gradle-kts-standalone.png">

- より良いエラー報告。以前はGradleデーモンからのエラーは別のログファイルを見ることができた。今ではGradleデーモンはエラーに関するすべての情報を直接返却し、ビルドツールウィンドウで表示される。これは時間と労力の節約になる。
# 標準ライブラリ
ここでは、1.4.0でKotlin標準ライブラリへのもっとも重要な変更をリストする。
- 共通のエラー処理API
- 配列とコレクションのための新しいAPI
- 文字列操作のための関数
- ビット操作
- deletegeプロパティの改善
- KTypeからJava Typeへの変換
- KotlinリフレクションのためのProguard設定
- 既存のAPIの改善
- 標準ライブラリ成果物のためのmodule-info記述子
- 非推奨
- 非推奨の実験的コルーチンの除外

## 共通のエラー処理API
次のAPI要素は標準ライブラリに移動されている。
- `Throwable.stackTraceToString()`拡張関数、これは、スタックトレースに付随するthrowableの詳細な説明を返却する。`Throwable.printStackTrace()`。これは標準エラー出力の詳細を出力する。
- `Throwable.addSuppressed()`関数。これは他の例外に渡すために隠す例外を指定する。`Throwable.suppressedExceptions`プロパティ。これはすべての隠された例外を返却する。
- `@Throws`アノテーション。これは関数が、JVMかNativeプラットフォームのプラットフォームメソッドにコンパイルするときにチェックされる例外型をリストする。
## 配列とコレクションのための新しいAPI
### コレクション
1.4.0では、標準ライブラリはコレクションと連携する多くの有益な関数を含んでいる。
- `setOfNotNull()`は、提示された引数の中ですべての非nullの要素からなる一式を作成する。
```Kotlin
val set = setOfNotNull(null, 1, 2, 0, null)
println(set) // [1,2,0]
```
- シーケンスのための`shuffled()`
```Kotlin
val numbers = (0 until 50).asSequence()
val result = numbers.map { it * 2 }.shuffled().take(5)
println(result.toList()) // 5個の100未満のランダムな偶数
```
- `onEach()`と`flatMap()`のための対応する`*Indexed()` これらがコレクションの要素に適用された演算は、パラメータとして要素インデックスを持つ。
```Kotlin
listOf("a", "b", "c", "d").onEachIndexed {
    index, item -> println(index.toString() + ":" + item)
} // 0:a 1:b 2:c 3:d

val list = listOf("hello", "kot", "lin", "world")
val kotlin = list.flatMapIndexed { index, item ->
    if (index in 1..2) item.toList() else emptyList() 
} 
// [k, o, t, l, i, n]
```
- `*OrNull()`の対応である`randomOrNull()`、`reduceOrNull()`、`reduceIndexedOrNull()`これらは空のコレクションについて、nullを返却する。
```Kotlin
val empty = emptyList<Int>()
empty.reduceOrNull { a, b -> a + b }
//empty.reduce { a, b -> a + b } // 例外: Empty collection can't be reduced.
```
- `runningFold()`は、`scan()`と`runningReduce()`の同義語であり、`fold()`と`reduce()`と同様にコレクションの要素に順番に与えられた演算を適用する。違いは、これらの新しい関数は、中間結果のすべての連続を返却する。
```Kotlin
val numbers = mutableListOf(0, 1, 2, 3, 4, 5)
val runningReduceSum = numbers.runningReduce { sum, item -> sum + item }
// [0, 1, 3, 6, 10, 15]
val runningFoldSum = numbers.runningFold(10) { sum, item -> sum + item }
// [10, 10, 11, 13, 16, 20, 25]
```
- `sumOf()`はセレクタ関数をとり、コレクションのすべての要素の合計を返却する。`sumOf()`は`Int`、`Long`、`Double`、`UInt`、`ULong`の型の合計を生成する。JVMでは、`BigInteger`、`BigDecimal`も利用可能である。
```Kotlin
val order = listOf<OrderItem>(
    OrderItem("Cake", price = 10.0, count = 1),
    OrderItem("Coffee", price = 2.5, count = 3),
    OrderItem("Tea", price = 1.5, count = 2))

val total = order.sumOf { it.price * it.count } // Double
val count = order.sumOf { it.count } // Int
```
- `min()`、`max()`拡張関数はKotlinコレクションAPI中で使用されている命名規約に適合させるため、`minOrNull()`、`maxOrNull()`に改名された。関数名の`*orNull`サフィックスはレシーバーのコレクションが空の場合、`null`を返却するという意味である。1.4では同様のことが`minBy()`、`maxBy()`、`minWith()`、`maxWith()`でも当てはまる。これらは`*orNull`の類義語を持つ。
- 新しい`minOf()`、`maxOf()`拡張は、コレクション要素について、与えられたセレクタ関数の最小と最大の値を返却する。
```Kotlin
data class OrderItem(val name: String, val price: Double, val count: Int)

fun main() {
    val order = listOf<OrderItem>(
        OrderItem("Cake", price = 10.0, count = 1),
        OrderItem("Coffee", price = 2.5, count = 3),
        OrderItem("Tea", price = 1.5, count = 2))
    val highestPrice = order.maxOf { it.price }
    println("The most expensive item in the order costs $highestPrice") // 10.0
}
```
`minOfWith()`、`maxOfWith()`もあり、これらは引数として`Comparator`をとる。また、すべての４つの関数の`*OrNull`バージョンは、空のコレクションについては`null`を返却する。

- `flatMap`と`flatMapTo`の新しいオーバーロードにより、レシーバーの型と合わない戻り値の型の変換をすることができる。つまり
  - `Iterable`、`Array`、`Map`については`Sequence`への変換
  - `Sequence`については`Iterable`への変換
```Kotlin
fun main() {
    val list = listOf("kot", "lin")
    val lettersList = list.flatMap { it.asSequence() }
    val lettersSeq = list.asSequence().flatMap { it.toList() }    
    println(lettersList)
    println(lettersSeq.toList())
}
```
- `removeFirst()`、`removeLast()`はミュータブルなリストから要素を削除するショートカットであり、これらの関数の`*orNull()`版がある。
### 配列
異なるコンテナ型と連携するときに一貫した体験を提供するために、配列のためにも新しい関数を追加した。
- `shuffle()`はランダムな順序で配列の要素を入れる
- `onEach()`はそれぞれの配列の要素に対してアクションを実行し、配列そのものを返却する。
- `associateWith()`と`associateTo()`は、配列の要素をキーとしたmapを組み立てる。
- 配列の部分範囲に対する`reverse()`は、部分範囲の要素の順序を逆にする。
- 配列の部分範囲に対する`sortDescending()は、部分範囲内の要素を降順にソートする。
- 配列の部分範囲に対する`sort()`と`sortWith()`は、今では共通ライブラリで利用可能である。

```Kotlin
fun main() {
    var language = ""
    val letters = arrayOf("k", "o", "t", "l", "i", "n")
    val fileExt = letters.onEach { language += it }
        .filterNot { it in "aeuio" }.take(2)
        .joinToString(prefix = ".", separator = "")
    println(language) // "kotlin"
    println(fileExt) // ".kt"

    letters.shuffle()
    letters.reverse(0, 3)
    letters.sortDescending(2, 5)
    println(letters.contentToString()) // [k, o, t, l, i, n] ※これは順序の変更には左右されない
}
```
さらに、`CharArray`/`ByteArray`と`String`の間の変換のために新しい関数がある。
- `ByteArray.decodeToString()`と`String.encodeToString()`
- `CharArray.concatToString()`と`String.toCharArray()`
```Kotlin
fun main() {
    val str = "kotlin"
    val array = str.toCharArray()
    println(array.concatToString()) // kotlin
}
```
### ArrayDeque
`ArrayDeque`クラス、両端キューの実装が追加された。両端キューにより、定数の償却時間でキューの先頭と末尾に要素を追加、または削除することができる。コードでキューやスタックが必要なときは、デフォルトで両端キューを使うことができる。
```Kotlin
fun main() {
    val deque = ArrayDeque(listOf(1, 2, 3))

    deque.addFirst(0)
    deque.addLast(4)
    println(deque) // [0, 1, 2, 3, 4]

    println(deque.first()) // 0
    println(deque.last()) // 4

    deque.removeFirst()
    deque.removeLast()
    println(deque) // [1, 2, 3]
}
```
`ArrayDeque`の実装は、水面下でリサイズ可能な配列を使う。それは循環バッファ、`Array`内に中身を保存し、一杯になったら`Array`をリサイズする。
## 文字列操作のための関数
1.4.0の標準ライブラリは文字列操作のためにAPI内に多くの役立つ改善を含んでいる。
- `StringBuilder`は役立つ新しい拡張関数を持つ。`set()`、`setRange()`、`deleteAt()`、`deleteRange`、`appendRange`など。
```Kotlin
fun main() {
    val sb = StringBuilder("Bye Kotlin 1.3.72")
    sb.deleteRange(0, 3)
    sb.insertRange(0, "Hello", 0 ,5)
    sb.set(15, '4')
    sb.setRange(17, 19, "0")
    print(sb.toString()) // Hello Kotlin 1.4.0

    }
```
## ビット操作
ビット操作のための新しい関数
- `countOneBits()`
- `countLeadingZeroBits()`
- `countTralingZerobBits()`
- `takeHighestOneBit()`
- `takeLowestOneBit()`
- `rotateLeft()`と`rotateRight()`(実験的)
```Kotlin
fun main() {
    val number = "1010000".toInt(radix = 2)
    println(number.countOneBits()) // 2
    println(number.countTrailingZeroBits()) // 4
    println(number.takeHighestOneBit().toString(2)) // 1000000
}
```
## delegateプロパティの改善
1.4.0では、Kotlinのdelegateプロパティで体験を改善する新しい特徴が追加されている。
- 今ではプロパティは別のプロパティにdelegate可能
- 新しい`PropertyDelegateProvider`インターフェイスが単一の宣言でdelegateプロパティを作ることを助ける
- `ReadWriteProperty`は今は`ReadOnlyProperty`を拡張し、どちらも読み取り専用のプロパティのために使用できる
新しいAPIとは別に、結果として生成されるバイトコードのサイズを減らすいくつかの最適化を行った。この最適化は[このブログ記事](https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond/#delegated-properties)に記載されている。 
## KTypeからJava Typeへの変換
標準ライブラリの新しい拡張プロパティ`KType.javaType`(現在実験的)は、全体の`kotlin-reflect`依存性を使わずに、Kotlin型から`java.lang.reflect.Type`を取得するのに役立つ。
```Kotlin
import kotlin.reflect.javaType
import kotlin.reflect.typeOf

@OptIn(ExperimentalStdlibApi::class)
inline fun <reified T> accessReifiedTypeArg() {
   val kType = typeOf<T>()
   println("Kotlin type: $kType")
   println("Java type: ${kType.javaType}")
}

@OptIn(ExperimentalStdlibApi::class)
fun main() {
   accessReifiedTypeArg<String>()
   // Kotlin type: kotlin.String
   // Java type: class java.lang.String
  
   accessReifiedTypeArg<List<String>>()
   // Kotlin type: kotlin.collections.List<kotlin.String>
   // Java type: java.util.List<java.lang.String>
}
```
## KotlinリフレクションのためのProguard設定
1.4.0以降、`kotlin-reflect.jar`の中に、KotlinリフレクションのためのProguard/R8の設定が埋め込まれている。この準備とともに、R8またはProguardを使っているほとんどのAndroidプロジェクトは、追加の構成を必要とせず、kotlin-reflectと連携するはずである。もはやkotlin-reflect内部のためにProguardルールをコピーペーストする必要はない。しかし留意すべきは、リフレクションをしようとするすべてのAPIを明示的に一覧化する必要はまだある。
### 既存のAPIの改善
- いくつかの関数は今ではnullレシーバと連携する。例えば、
  - 文字列についての`toBoolean()`
  - 配列についての`contentEquals()`、`contentHashCode()`、`contentToString()`
- `Double`と`Float`の`NaN`、`NEGATIVE_INFITINY`、`POSITIVE_INFINITY`は、今では`const`として宣言されているため、それらをアノテーションの引数として使用することができる。
- 新しい定数である`Double`と`Float`の`SIZE_BITS`、`SIZE_BYTES`は、バイナリ形式でインスタンスを表現するために使用するビットやバイト数を含んでいる。
- `maxOf()`、`minOf()`トップレベル関数は、可変長引数(`vararg`)を受け取ることができる。
## 標準ライブラリ成果物のためのmodule-info記述子
Kotlin1.4.0では、デフォルトの標準ライブラリの成果物に、モジュール情報である`module-info.java`が追加されている。これは[jlinkツール](https://docs.oracle.com/en/java/javase/11/tools/jlink.html)で使用し、アプリで必要なプラットフォームモジュールのみを含むカスタムなJavaランタイムを生成する。以前からKotlin標準ライブラリとjlinkを使用することはできていたが、そのために成果物を、あるものは「modular」分類名として、分割する必要があり、全体のセットアップが簡単ではなかった。
Androidでは、Android Gradleプラグインバージョン3.2以上を使うことを確認してほしいが、module-infoを使って正しくjarを処理することができる。
## 非推奨
### DoubleとFloatのtoShort()、toByte()
DoubleとFloatのtoShort()、toByte()は非推奨とされた。なぜなら、これらは値の範囲と値のサイズをナローイングするために、予期せぬ結果を引き起こすことがありうるためである。
浮動小数を`Byte`や`Short`に変換するためには、2ステップでの変換を使うこと。1つめはIntに変換し、そのあとで目的の型にそれを再度変換すること。
### 浮動小数の配列についてのcontains()、indexOf()、lastInexOf()
`FloatArray`と`DoubleArray`の`contains()`、`indexOf()`、`lastIndexOf()`拡張関数は非推奨となった。なぜなら、それらはIEEE754の等値性を使用しており、いくつかのまれなケースで全体の順序の等値性に矛盾するからである。詳細はこの[問題](https://youtrack.jetbrains.com/issue/KT-28753)を参照のこと。
### min()とmax()コレクション関数
`minOrNull()`と`maxOrNull()`のため、`min()`と`max()`コレクション関数は非推奨となった。これは空のコレクションについては`null`を返却するという、ふるまいをより反映している。詳細はこの[問題](https://youtrack.jetbrains.com/issue/KT-38854)を参照のこと。
## 非推奨の実験的コルーチンの排除
`kotlin.coroutines.experimental`APIは、1.3.0でkotlin.coroutinesのため、非推奨だった。1.4.0では、標準ライブラリからの削除をすることで、`kotlin.coroutines.experimental`のための非推奨サイクルを完了した。JVMでまだそれを使用する人々のため、すべての実験的コルーチンAPIをもつ`kotlin-coroutines-experimental-compat.jar`という互換性成果物を提供した。それはMavenに配信され、票運ライブラリと並んで、Kotlinディストリビューションに含まれている。
# 安定したJSONシリアライズ
Kotlin1.4.0とともに、kotlinx.serialization 1.0.0-RCの最初の安定バージョンが出荷されている。今では安定した`kotlinx-serialization-core`(以前は`kotlinx-serialization-runtime`として知られていた)でJSONシリアライズAPIを宣言できることを喜ばしく思う。他のシリアライズ形式のライブラリはコアライブラリのいくつかの高度な部分と一緒に、実験的なままである。
JSONシリアライズのためのAPIは、より一貫性を持ち、使いやすくするため、大幅に修正された。今後は後方互換のやり方で、JSONシリアライズAPIは開発され続けるだろう。しかし、以前のバージョンを使っていた人は、1.0.0-RCに移行するときに、いくつかコードを修正する必要がある。これを助けるため、[**Kotlin Serialization Guide**](https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/serialization-guide.md)が提供されている。これは`kotlinx-serialization`のドキュメントの完全なセットである。これは、最も重要な特徴を使う処理を案内し、直面するかもしれない、いかなる問題に対処することに役立つ。

:::note warn
注意：`kotlinx-serialization` 1.0.0-RCはKotlinコンパイラ1.4とのみ、連携する。より古いコンパイラバージョンとは互換性が無い。
:::

# スクリプトとREPL
1.4.0では、Kotlinのスクリプトは他の更新と一緒に多くの機能的、性能的な改善から、恩恵を受けている。ここにいくつかの重要な変更がある。
- 新しい依存性解決API
- 新しいREPL API
- コンパイルされたスクリプトキャッシュ
- 成果物の改名
Kotlinでのスクリプトをより親しみやすくするため、[サンプルプロジェクト](https://github.com/Kotlin/kotlin-script-examples)を用意した。これは標準的なスクリプト(`*.main.kts`)の例と、Kotlin Scripting APIとカスタムスクリプト定義の使い方のを含んでいる。どうか試して[issue tracker](https://youtrack.jetbrains.com/issues/KT)を使ってフィードバックを共有してほしい。
## 新しい依存性解決API
1.4.0では(Maven成果物のような)外部依存性を解決する新しいAPIがその実装と一緒に導入された。このAPIは新しい成果物である`kotlin-scripting-dependencies`と`kotlin-scripting-dependencies-maven`で発行されている。以前の`kotlin-script-util`ライブラリでの依存性解決機能は、今は非推奨である。
## 新しいREPL API
新しい実験的REPL APIは今は、Kotlin Scripting APIの一部である。発行された成果物にいくつかの実装もあり、いくつかはコード補完のような高度な機能も持っている。このAPIは[Kotlin Jupyterカーネル](https://blog.jetbrains.com/kotlin/2020/05/kotlin-kernel-for-jupyter-notebook-v0-8/)で使われており、今では自分のカスタムシェルやREPLで試すことができる。
## コンパイルされたスクリプトキャッシュ
Kotlin Scripting APIは今はコンパイルされたスクリプトキャッシュを実装する能力を提供しており、変更されていないスクリプトの後続の実行を大幅に高速化する。デフォルトの高度な実装である`kotlin-main-kts`はすでに自分のキャッシュを持っている。
## 成果物の改名
成果物の名前についての混乱を避けるため、`kotlin-scripting-jsr223-embeddable`と`kotlin-scripting-jvm-host-embeddable`を単に`kotlin-scripting-jsr223`と`kotlin-scripting-jvm-host`に改名した．これらの成果物は`kotlin-compiler-embeddable`成果物に依存しており、それは利用の衝突を避けるため、同梱のサードパーティのライブラリを隠している。この改名とともに、スクリプト成果物のデフォルトである`kotlin-compiler-embeddable`(一般により安全である)を利用していく。もし何らかの理由で、隠されていない`kotlin-compiler`成果物に依存した成果物が必要なら、`-unshaeded`サフィックスのついた成果物バージョン、例えば`kotlin-scripting-jsr223-unshaeded`を使用すること。留意すべきは、この成果物の改名は、直接使用することになっているスクリプト成果物にのみ影響し、他の成果物の名前は変更がない。
# Kotlin 1.4への移行
Kotlinプラグインの移行ツールは、Kotlinの以前のバージョンから1.4へ移行をするのに役立つ。
単にKotlinバージョンを`1.4.0`に変更し、GradleまたはMavenプロジェクトを再インポートすることで、IDEは移行するか尋ねるだろう。
もし同意すると、移行コードのインスペクションが動き、コードをチェックし、1.4.0では動作しない、あるいは非推奨のものの修正を提案するだろう。
コードインスペクションは異なる[深刻度](https://www.jetbrains.com/help/idea/configuring-inspection-severities.html)を持ち、提案を受け入れるか無視するかの決定を支援する。
Kotlin 1.4.0は[機能リリース](https://kotlinlang.org/docs/kotlin-evolution.html#feature-releases-and-incremental-releases)であり、それ故、言語に対して互換性のない変更をもたらすことがありうる。そのような変更の詳細は、[Kotlin 1.4互換性ガイド](https://kotlinlang.org/docs/compatibility-guide-14.html)を参照のこと。