Prohibit declarations of repeatable annotation classes whose container annotation violates JLS = 1.6.20: fix the downcast behavior in other affected cases Short summary: Kotlin will avoid converting numeric values automatically to a primitive numeric type where only a downcast to that type was needed semantically Prevent implicit coercions between different numeric types Short summary: Kotlin 1.7 will change how it loads and interprets type nullability annotations in Java codeġ.4.30: introduce warnings for cases where more precise type nullability could lead to an errorġ.7.0: infer more precise nullability of Java types, -XXLanguage:-TypeEnhancementImprovementsInStrictMode can be used to temporarily revert to the pre-1.7 behavior Type nullability enhancement improvements Short summary: Kotlin 1.6 will report an error for arguments of super constructor call of companion and regular objects if the receiver of such arguments refers to the containing declarationġ.5.20: introduce a warning on the problematic argumentsġ.6.0: raise this warning to an error, -XXLanguage:-ProhibitSelfCallsInNestedObjects can be used to temporarily revert to the pre-1.6 behavior Prohibit access to class members in the super constructor call of its companion and nested objects >= 1.8: repurpose some deprecated constructs for new language features Short summary: Kotlin 1.6 will deprecate several confusing grammar constructs in when condition expressionsġ.6.20: introduce a deprecation warning on the affected expressions Short summary: Kotlin 1.6 will warn about the when statement with an enum, sealed, or Boolean subject being non-exhaustiveġ.6.0: introduce a warning when the when statement with an enum, sealed, or Boolean subject is non-exhaustive (error in the progressive mode)ĭeprecate confusing grammar in when-with-subject Language Make when statements with enum, sealed, and Boolean subjects exhaustive by default Compatibility of Kotlin code from the other languages perspective (for example, from Java) is out of the scope of this document. Remember that those definitions are given only for pure Kotlin. Source: source-incompatible change stops code that used to compile fine (without errors or warnings) from compiling anymoreīinary: two binary artifacts are said to be binary-compatible if interchanging them doesn't lead to loading or linkage errorsīehavioral: a change is said to be behavioral-incompatible if the same program demonstrates different behavior before and after applying the change In this document we introduce several kinds of compatibility: While most of the language changes were already announced through other channels, like update changelogs or compiler warnings, this document summarizes them all, providing a complete reference for migration from Kotlin 1.5 to Kotlin 1.6. The former says that constructs which obstruct language evolution should be removed, and the latter says that this removal should be well-communicated beforehand to make code migration as smooth as possible. Keeping the Language Modern and Comfortable Updates are among the fundamental principles in Kotlin Language Design.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |