# Kotlin 演進 [TOC] ## 實用主義演進原則 語言的設計是石頭鑄造的（譯注：原文為“cast in stone”，意為“最終定論，板上釘釘”，此處雙關），但這塊石頭相當柔軟，經過一番努力，我們可以后期重塑它。 Kotlin 設計團隊 Kotlin 旨在成為程序員的實用工具。在語言演進方面，它的實用主義本質遵循以下原則： * 一直保持語言的現代性。 * 與用戶保持持續的反饋循環。 * 使版本更新對用戶來說是舒適的。 由于這是理解 Kotlin 如何向前發展的關鍵，我們來展開來看這些原則。 **保持語言現代性**。我們承認系統隨著時間的推移積累了很多遺留問題。曾經是尖端技術的東西如今可能已經無可救藥地過時了。我們必須改進語言，使其與用戶需求保持一致、與用戶期望保持同步。這不僅包括添加新特性，還包括逐步淘汰不再推薦用于生產的舊特性，并且完全成為歷史特性。 **舒適的更新**。如果沒有適度謹慎地進行不兼容的變更（例如從語言中刪除內容）可能會導致從一個版本到下一個版本的痛苦遷移過程。我們會始終提前公布這類變更，將相應內容標記為已棄用并 _在變更發生之前_ 提供自動化的遷移工具。當語言發生變更之時，我們希望世界上絕大多數代碼都已經更新，這樣遷移到新版本就沒有問題了。 **反饋循環**。 通過棄用周期需要付出很大的努力，因此我們希望最大限度地減少將來不兼容變更的數量。除了使用我們的最佳判斷之外，我們相信在現實生活中試用是驗證設計的最佳方法。在最終定論之前，我們希望已經實戰測試過。這就是為什么我們利用每個機會在語言的生產版本中提供我們早期版設計，只是帶有_實驗性_ 狀態。實驗性特性并不穩定，可以隨時更改，選擇使用它們的用戶明確表示已準備好了應對未來的遷移問題。這些用戶提供了寶貴的反饋，而我們收集這些反饋來迭代設計并使其堅如磐石。 ## 不兼容的變更 如果從一個版本更新到另一個版本時，一些以前工作的代碼不再工作，那么它是語言中的 _不兼容的變更_ （有時稱為“破壞性變更”）。在一些場景中“不再工作”的確切含義可能會有爭議，但是它肯定包含以下內容： * 之前編譯運行正常的代碼現在（編譯或鏈接）失敗并報錯。這包括刪除語言結構以及添加新的限制。 * 之前正常執行的代碼現在拋異常了。 The less obvious cases that belong to the "grey area" include handling corner cases differently, throwing an exception of a different type than before, changing behavior observable only through reflection, changes in undocumented/undefined behavior, renaming binary artifacts, etc. Sometimes such changes are very important and affect migration experience dramatically, sometimes they are insignificant. 絕對不是不兼容的變更的一些示例包括 * Adding new warnings. * Enabling new language constructs or relaxing limitations for existing ones. * Changing private/internal APIs and other implementation details. The principles of Keeping the Language Modern and Comfortable Updates suggest that incompatible changes are sometimes necessary, but they should be introduced carefully. Our goal is to make the users aware of upcoming changes well in advance to let them migrate their code comfortably. Ideally, every incompatible change should be announced through a compile-time warning reported in the problematic code (usually referred to as a _deprecation warning_) and accompanied with automated migration aids. So, the ideal migration workflow goes as follows: * Update to version A (where the change is announced) * See warnings about the upcoming change * Migrate the code with the help of the tooling * Update to version B (where the change happens) * See no issues at all In practice some changes can't be accurately detected at compile time, so no warnings can be reported, but at least the users will be notified through Release notes of version A that a change is coming in version B. ### Dealing with compiler bugs Compilers are complicated software and despite the best effort of their developers they have bugs. The bugs that cause the compiler itself to fail or report spurious errors or generate obviously failing code, though annoying and often embarrassing, are easy to fix, because the fixes do not constitute incompatible changes. Other bugs may cause the compiler to generate incorrect code that does not fail: e.g. by missing some errors in the source or simply generating wrong instructions. Fixes of such bugs are technically incompatible changes (some code used to compile fine, but now it won't any more), but we are inclined to fixing them as soon as possible to prevent the bad code patterns from spreading across user code. In our opinion, this serves the principle of Comfortable Updates, because fewer users have a chance of encountering the issue. Of course, this applies only to bugs that are found soon after appearing in a released version. ## Decision Making [JetBrains](https://jetbrains.com), the original creator of Kotlin, is driving its progress with the help of the community and in accord with the [Kotlin Foundation](/foundation/kotlin-foundation.html). All changes to the Kotlin Programming Language are overseen by the [Lead Language Designer](/foundation/kotlin-foundation.html#lead-designer) (currently Andrey Breslav). The Lead Designer has the final say in all matters related to language evolution. Additionally, incompatible changes to fully stable components have to be approved to by the [Language Committee](/foundation/kotlin-foundation.html#language-committee) designated under the [Kotlin Foundation](/foundation/kotlin-foundation.html) (currently comprised of Jeffrey van Gogh, William R. Cook and Andrey Breslav). The Language Committee makes final decisions on what incompatible changes will be made and what exact measures should be taken to make user updates comfortable. In doing so, it relies on a set of guidelines available [here](/foundation/language-committee-guidelines.html). ## Feature Releases and Incremental Releases Stable releases with versions 1.2, 1.3, etc. are usually considered to be _feature releases_ bringing major changes in the language. Normally, we publish _incremental releases_, numbered 1.2.20, 1.2.30, etc, in between feature releases. Incremental releases bring updates in the tooling (often including features), performance improvements and bug fixes. We try to keep such versions compatible with each other, so changes to the compiler are mostly optimizations and warning additions/removals. Experimental features may, of course, be added, removed or changed at any time. Feature releases often add new features and may remove or change previously deprecated ones. Feature graduation from experimental to stable also happens in feature releases. ### EAP Builds Before releasing stable versions, we usually publish a number of preview builds dubbed EAP (for "Early Access Preview") that let us iterate faster and gather feedback from the community. EAPs of feature releases usually produce binaries that will be later rejected by the stable compiler to make sure that possible bugs in the binary format survive no longer than the preview period. Final Release Candidates normally do not bear this limitation. ### Experimental features According to the Feedback Loop principle described above, we iterate on our designs in the open and release versions of the language where some features have the _experimental_ status and _are supposed to change_. Experimental features can be added, changed or removed at any point and without warning. We make sure that experimental features can't be used accidentally by an unsuspecting user. Such features usually require some sort of an explicit opt-in either in the code or in the project configuration. Experimental features usually graduate to the stable status after some iterations. ### Status of different components To check the stability status of different components of Kotlin (Kotlin/JVM, JS, Native, various libraries, etc), please consult [this link](components-stability.html). ## Libraries A language is nothing without its ecosystem, so we pay extra attention to enabling smooth library evolution. Ideally, a new version of a library can be used as a "drop-in replacement" for an older version. This means that upgrading a binary dependency should not break anything, even if the application is not recompiled (this is possible under dynamic linking). On the one hand, to achieve this, the compiler has to provide certain ABI stability guarantees under the constraints of separate compilation. This is why every change in the language is examined from the point of view of binary compatibility. On the other hand, a lot depends on the library authors being careful about which changes are safe to make. Thus it's very important that library authors understand how source changes affect compatibility and follow certain best practices to keep both APIs and ABIs of their libraries stable. Here are some assumptions that we make when considering language changes from the library evolution standpoint: * Library code should always specify return types of public/protected functions and properties explicitly thus never relying on type inference for public API. Subtle changes in type inference may cause return types to change inadvertently, leading to binary compatibility issues. * Overloaded functions and properties provided by the same library should do essentially the same thing. Changes in type inference may result in more precise static types to be known at call sites causing changes in overload resolution. Library authors can use the @Deprecated and @Experimental annotations to control the evolution of their API surface. Note that @Deprecated(level=HIDDEN) can be used to preserve binary compatibility even for declarations removed from the API. Also, by convention, packages named "internal" are not considered public API. All API residing in packages named "experimental" is considered experimental and can change at any moment. We evolve the Kotlin Standard Library (kotlin-stdlib) for stable platforms according to the principles stated above. Changes to the contracts for its API undergo the same procedures as changes in the language itself. ## Compiler Keys Command line keys accepted by the compiler are also a kind of public API, and they are subject to the same considerations. Supported flags (those that don't have the "-X" or "-XX" prefix) can be added only in feature releases and should be properly deprecated before removing them. The "-X" and "-XX" flags are experimental and can be added and removed at any time. ## Compatibility Tools As legacy features get removed and bugs fixed, the source language changes, and old code that has not been properly migrated may not compile any more. The normal deprecation cycle allows a comfortable period of time for migration, and even when it's over and the change ships in a stable version, there's still a way to compile unmigrated code. ### Compatibility flags We provide the -language-version and -api-version flags that make a new version emulate the behaviour of an old one, for compatibility purposes. Normally, at least one previous version is supported. This effectively leaves a time span of two full feature release cycles for migration (which usually amounts to about two years). Using an older kotlin-stdlib or kotlin-reflect with a newer compiler without specifying compatibility flags is not recommended, and the compiler will report a [warning](compatibility-modes.html) when this happens. Actively maintained code bases can benefit from getting bug fixes ASAP, without waiting for a full deprecation cycle to complete. Currently such project can enable the -progressive flag and get such fixes enabled even in incremental releases. All flags are available on the command line as well as [Gradle](../using-gradle.html#編譯器選項) and [Maven](../using-maven.html#指定編譯器選項). ### Evolving the binary format Unlike sources that can be fixed by hand in the worst case, binaries are a lot harder to migrate, and this makes backwards compatibility very important in the case of binaries. Incompatible changes to binaries can make updates very uncomfortable and thus should be introduced with even more care than those in the source language syntax. For fully stable versions of the compiler the default binary compatibility protocol is the following: * All binaries are backwards compatible, i.e. a newer compiler can read older binaries (e.g. 1.3 understands 1.0 through 1.2), * Older compilers reject binaries that rely on new features (e.g. a 1.0 compiler rejects binaries that use coroutines). * Preferably (but we can't guarantee it), the binary format is mostly forwards compatible with the next feature release, but not later ones (in the cases when new features are not used, e.g. 1.3 can understand most binaries from 1.4, but not 1.5). This protocol is designed for comfortable updates as no project can be blocked from updating its dependencies even if it's using a slightly outdated compiler. Please note that not all target platforms have reached this level of stability (but Kotlin/JVM has).