Kotlin 1.4および将来の場所を楽しみにして

Kotlin 1.4は春2020年に発売される、開発チームは「レッツKotlinは、すべての作業のための信頼できるパートナーになると、デフォルトの言語があなたのミッションを選択している」:. Kotlinのブログに自分のビジョンを提示ので、開発チームの意志開発者は、すべてのプラットフォーム上でKotlinを使用することができます。

開発チームの報告によると、Kotlin 1.4は、品質と性能に焦点を当てます。今Kotlinは、全体的な体験を改善することであるため、新機能を追加することよりも重要です。また、高速の建設は、通常、ほとんどの問題は、ユーザーが心配であることから、その開発チームはこの問題を解決するためのツールチェーンを改善しています。全体的なビルド時間が短い十分であるように、開発チームにもかかわらず、コンパイル速度をスピードアップするために、より多くのユーザーが記述したコード：しかし、生産の自然な成長に追いつくと、徐々にコードベースを向上させます。このため、開発チームの計画はより迅速にそれを作るためのコンパイラを再実装します。

新しいコンパイラ

達成するために、新しいコンパイラのターゲットはより急速になりつつあり、統一Kotlinは、すべてのプラットフォームをサポートし、コンパイラの拡張機能のAPIを提供します。あなたは、このプロセスのよりスムーズに行うことができます、これは複数年の作業になりますが、新しいリリースのいくつかの部分が1.4で実装されますので、開発チームは、かなり時間が開始されました。

一部の機能もリリースされている;例えば、あなたがしようとした場合、型推論のための新しいアルゴリズム新しいコンパイラの一部であり、。同じセクションを処理する他の方法。つまり、2つのバージョンが利用できるようになり、新旧両方のバージョンでは、いくつかの時間のためのテスト・モードになります。新しい安定は、それがデフォルトのバージョンになりますとき。

新しいフロントエンド（フロントエンド）加速

新しいコンパイラ開発チームは、新しいフロントエンドの実装からレートの増加を見込んでいます。

いくつかの背景情報を提供するために、ソースファイルをコンパイルすることができ、吸収し、徐々に実行可能コードのパイプラインに変換したいと思います。このパイプラインの最初のステップは、一般的に、フロントエンドコンパイラとして知られています。これは、コードと名前、型チェックなどを解析します。IDEでこのコンパイラのこの部分も強調構文エラーに使用され、プロジェクト内の検索記号の使用を定義するためにナビゲートすることができます。これは、 kotlinc 開発チームの希望はより速くそれを作るために今、最も時間を費やしステップ。

現在の実装は完了していない、と1.4に来ることはありません。しかし、時間のかかる作業のほとんどは、それによって行われているので、私たちはスピードの効果を期待することができます。ベンチマーク（YouTrackコンパイルおよびコンパイラ自体Kotlinは）新しいフロントエンドの速度は約4.5倍の高速化、従来のフロントエンドであることを示しています。

ユニファイドバックエンドとスケーラビリティ

フロントエンドでのコードの解析が完了した後、後端が実行可能ファイルを生成します。Kotlin / JVM、Kotlin / JSとKotlin /ネイティブ：現在3つのバックエンドがあります。最初の二つは、過去に書かれた独立しており、何のコードシェアは存在しません。我々が起動すると、新しいインフラストラクチャに基づいてKotlin /ネイティブは、同様の機能バイトコード仮想マシンとして（内部表現）内部Kotlinコードを中心に構築され、機能する表します。

今、チームは計画と同じ内部表現には、2つの他のバックエンドを移行します。そのため、彼らは、バックエンド・ロジックの多くを共有し、一度だけ、ほとんどの機能は、最適化とバグ修正のすべてのターゲットの実装を可能にするために、統一されたラインを持っています。

徐々に新しいバックエンドに、しかし1.4で、デフォルトで移行されるが、それらは有効にされる可能性は低いですが、ユーザーが明示的にそれらを使用することを選択することができるようになります。

クロスプラットフォームのコンパイラ拡張のための共通のバックエンドインフラストラクチャは、ドアを開けました。このパイプラインでは、いくつかのカスタム処理および/または変換を追加することができ、これらは自動的に処理され、すべてのターゲット用に変換されます。（そのプラグ内蔵したコンパイラを含む1.4になります（APIは後に安定化される）、そのような拡張公共のAPIを提供していませんが、開発チームは、パートナーと協力して Jetpackの作曲を緊密に協力しに）。

新しい言語機能：

Kotlin 1.4は、いくつかの新しい言語機能を提供します。

SAM変換Kotlinクラス

コミュニティの開発チームはKotlinクラスの導入（要求した KT-7770 SAM変換のサポート）。抽象クラスインターフェースまたはメソッドをパラメータとして期待されている場合には、パラメータとして渡されるラムダ、アプリケーションがSAMに変換します。次に、コンパイラは自動的に抽象クラスのメンバ関数の実装のラムダ例を変換します。

SAMの変換は、現在のJavaインターフェースと抽象クラスに適用されます。デザインの背後にあるオリジナルのアイデアは明らかに、このようなユースケースのための使用のタイプの関数です。しかし、それは、タイプと機能タイプエイリアスが判明し、すべてのユースケースをカバーすることはできません、開発者が多いだけでなく、Javaのインターフェイスは、SAM変換することができます保持します。

ジャワとは異なり、Kotlinは、各インタフェースの抽象メソッドSAM変換を使用することができました。開発チームは、明確にする必要がありインターフェースの意図は、SAMの変換に適していると考えています。したがって、SAMのインタフェースを定義するために、あなたが使用する必要があり fun 、それが機能インタフェースとして使用することができることを強調するために、キーワードタグにインターフェースを：

fun interface Action {
    fun run()
}
 
fun runAction(a: Action) = a.run()
 
fun main() {
    runAction {
        println("Hello, KotlinConf!")
    }
}

アルゴリズムがサポートすることを通過し、ラムダとするだけでなく、新たな型推論に注意してください 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 機能。

投稿者：JetBrainsの中国