You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/md/kotlin.core/annotations.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,9 @@
2
2
3
3
Annotations are a form of syntactically-defined metadata which may be associated with different entities in a Kotlin program.
4
4
Annotations are specified in the source code of the program and may be accessed on a particular platform using platform-specific mechanisms both by the compiler (and source-processing tools) and at runtime (using [reflection][Reflection] facilities).
5
-
Values of annotation types cannot be created directly, but can be operated on when accessed using platform-specific facilities.
5
+
Values of annotation types can also be created directly, but are usually operated on using platform-specific facilities.
6
+
7
+
> Note: before Kotlin 1.6, annotation types could not be created directly.
Copy file name to clipboardExpand all lines: docs/src/md/kotlin.core/cdfa.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1390,7 +1390,7 @@ See the [corresponding section][Smart casts] for details.
1390
1390
1391
1391
#### Function contracts
1392
1392
1393
-
> Note: as of Kotlin 1.5.0, contracts for user-defined functions are an experimental feature and, thus, not described here
1393
+
> Note: as of Kotlin $\currentKotlinMajorVersion{}$, contracts for user-defined functions are an experimental feature and, thus, not described here
1394
1394
1395
1395
Some standard-library functions in Kotlin are defined in such a way that they adhere to a specific *call contract* that affects the way calls to such functions are analyzed from the perspective of the caller's control flow graph.
1396
1396
A function's call contract consists of one or more *effects*.
Copy file name to clipboardExpand all lines: docs/src/md/kotlin.core/declarations.md
+72-24Lines changed: 72 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,8 +38,6 @@ There are three kinds of classifier declarations:
38
38
39
39
> Important: [object literals] are similar to [object declarations][Object declaration] and are considered to be anonymous classifier declarations, despite being [expressions].
40
40
41
-
42
-
43
41
#### Class declaration
44
42
45
43
A simple class declaration consists of the following parts.
@@ -627,7 +625,11 @@ Annotation classes have the following properties:
627
625
>Note:annotation classes can have type parameters, but cannot use them as types for their primary constructor parameters.
628
626
>Their main use isfor various annotation processing tools, which can access the type arguments from the source code.
629
627
630
-
Annotation classes cannot be constructed directly unless passed as arguments to other annotations, but their primary constructors are used when specifying [code annotations][Annotations] for other entities.
628
+
The main use of annotation classes iswhen specifying [code annotations][Annotations] for other entities.
629
+
Additionally, annotation classes can be instantiated directly, for cases when you require working with an annotation instance directly.
630
+
For example, thisis needed for interoperability with some JavaannotationAPIs, asinJava you can implement an annotationinterfaceand then instantiate it.
631
+
632
+
>Note: before Kotlin1.6, annotation classes could not be instantiated directly.
631
633
632
634
>Examples:
633
635
>
@@ -659,9 +661,6 @@ Annotation classes cannot be constructed directly unless passed as arguments to
659
661
660
662
#### Valueclassdeclaration
661
663
662
-
>Note:as of Kotlin1.5.0, user-defined value classes are an experimental feature.
663
-
>Thereis, however, a number of value classes inKotlin standard library.
664
-
665
664
Aclassmay be declared a **value** class by using `inline` or `value` modifier in its declaration.
666
665
Value classes must adhere to the following limitations:
667
666
@@ -670,18 +669,21 @@ Value classes must adhere to the following limitations:
670
669
*Value classes must have a primary constructor with a single property constructor parameter, which is the data property of the class;
671
670
*This property cannot be specified as `vararg` constructor argument;
672
671
*This property must be declared `public`;
673
-
*This property must be of [a runtime-available type][Runtime-available types];
674
672
*They must notoverride `equals` and `hashCode` member functions of `kotlin.Any`;
675
673
*They must not have any base classes besides `kotlin.Any`;
676
674
*No other properties of thisclassmay have backing fields.
677
675
678
676
>Note: `inline` modifier for value classes is supported as a legacy feature for compatibility with Kotlin1.4 experimental inline classes and will be deprecated in the future.
679
677
678
+
>Note: before Kotlin1.8, value classes supported only properties of [a runtime-available types].
679
+
680
680
Value classes implicitly override `equals` and `hashCode` member functions of `kotlin.Any` by delegating them to their only data property.
681
681
Unless `toString` is overridden by the value classdefinition, it is also implicitly overridden by delegating to the data property.
682
682
In addition to these, an value classis allowed by the implementation to be **inlined** where applicable, so that its data property is operated on instead.
683
683
This also means that the property may be boxed back to the value classby using its primary constructor at any time if the compiler decides it is the right thing to do.
684
684
685
+
>Note:when inlining a data property of a non-runtime-available type $U$ (i.e., a non-reified type parameter), the property is considered to be of type, which is the runtime-available upper bound of $U$.
686
+
685
687
Due to these restrictions, it is highly discouraged to use value classes with the [reference equality operators][Reference equality expressions].
686
688
687
689
>Note:in the future versions of Kotlin, value classes may be allowed to have more than one data property.
@@ -694,13 +696,16 @@ In other aspects they are similar to classes, therefore we shall specify their d
694
696
* An interface can be declared only in a declaration scope;
695
697
* Additionally, an interface cannot be declared in an [object literal][Object literals];
696
698
* An interface cannot have a class as its supertype;
699
+
* This also means it is not considered to have `kotlin.Any` as its supertype for the purposes of [inheriting] and [overriding] callables;
700
+
* However, it is still considered to be a subtype of `kotlin.Any` w.r.t. [subtyping];
697
701
* An interface cannot have a constructor;
698
702
* Interface properties cannot have initializers or backing fields;
699
703
* Interface properties cannot be delegated;
700
704
* An interface cannot have inner classes;
701
705
* An interface and all its members are implicitly open;
702
706
* All interface member properties and functions are implicitly public;
703
-
* Trying to declare a non-public member property or function in an interface is an compile-time error.
707
+
* Trying to declare a non-public member property or function in an interface is an compile-time error;
708
+
* Interface member properties and functions without implementation are implicitly abstract.
704
709
705
710
##### Functional interface declaration
706
711
@@ -947,7 +952,7 @@ In other cases return type $R$ cannot be omitted and must be specified explicitl
947
952
> As type `kotlin.Nothing` has a [special meaning][`kotlin.Nothing`-typesystem] in Kotlin type system, it must be specified explicitly, to avoid spurious `kotlin.Nothing` function return types.
948
953
949
954
Function body $b$ is optional; if it is omitted, a function declaration creates an *abstract* function, which does not have an implementation.
950
-
This is allowed only inside an [abstract class][Abstract classes-declarations].
955
+
This is allowed only inside an [abstract class][Abstract classes-declarations] or an [interface][Interface declaration].
951
956
If a function body $b$ is present, it should evaluate to type $B$ which should satisfy $B <: R$.
@@ -1138,22 +1147,61 @@ Particular platforms may introduce additional restrictions or guarantees for the
1138
1147
> cinl()
1139
1148
> noinl()
1140
1149
>// all arguments may be passed as inline
1141
-
> fee(inl)
1142
-
> fee(cinl)
1143
-
> fee(noinl)
1144
-
>// passing to non-inline function
1145
-
>// is allowed only for noinline parameters
1150
+
> inlineParameter(inl)
1151
+
> inlineParameter(cinl)
1152
+
> inlineParameter(noinl)
1153
+
>// only noinline arguments may be passed as noinline
1154
+
> noinlineParameter(inl) // not allowed
1155
+
> noinlineParameter(cinl) // not allowed
1156
+
> noinlineParameter(noinl)
1157
+
>// noinline/crossinline arguments may be passed as crossinline
1158
+
> crossinlineParameter(inl) // not allowed
1159
+
> crossinlineParameter(cinl)
1160
+
> crossinlineParameter(noinl)
1161
+
>// only noinline arguments may be passed to non-inline functions
1146
1162
> bar(inl) // not allowed
1147
1163
> bar(cinl) // not allowed
1148
-
> bar(noinl) // allowed
1149
-
>// capturing in a lambda expression
1150
-
>// is allowed for noinline/crossinline parameters
1164
+
> bar(noinl)
1165
+
>// noinline/crossinline parameters may be captured in lambda literals
1151
1166
> bar({ inl() }) // not allowed
1152
-
> bar({ cinl() })// allowed
1153
-
> bar({ noinl() })// allowed
1167
+
> bar({ cinl() })
1168
+
> bar({ noinl() })
1154
1169
> }
1155
1170
> ```
1156
1171
1172
+
#### Infix functions
1173
+
1174
+
A function may be declared as an *infix* function by using a special `infix` modifier.
1175
+
Aninfix function can be called in an [infix form][Infix function call], i.e., `a foo b` instead of `a.foo(b)`.
1176
+
1177
+
To be a valid infix function, function $F$ must satisfy the following requirements.
1178
+
1179
+
* $F$ has a dispatch or an extension [receiver][Receivers]
1180
+
* $F$ has exactly one parameter
1181
+
1182
+
TODO(Examples)
1183
+
1184
+
#### Local function declaration
1185
+
1186
+
A function may be declared *locally* inside a [statement scope][Scopesand identifiers] (namely, inside another function).
1187
+
Such declarations are similar to [function literals] in that they may capture values available in the scope they are declared in.
1188
+
Otherwise they are similar to regular function declarations.
1189
+
1190
+
```kotlin
1191
+
funfoo() {
1192
+
var x =2
1193
+
1194
+
funbar(): Int {
1195
+
return x
1196
+
}
1197
+
1198
+
println(bar()) // 2
1199
+
1200
+
x =42
1201
+
println(bar()) // 42
1202
+
}
1203
+
```
1204
+
1157
1205
#### Tail recursion optimization
1158
1206
1159
1207
A function may be declared *tail-recursive* by using a special `tailrec` modifier.
@@ -1633,7 +1681,7 @@ The scope where it is accessible is defined by its [*visibility modifiers*][Decl
1633
1681
1634
1682
> Examples:
1635
1683
> ```kotlin
1636
-
> // simple typ ealias declaration
1684
+
> // simple typealias declaration
1637
1685
> typealias IntList = List<Int>
1638
1686
> // parameterized type alias declaration
1639
1687
> // T has out variance implicitly
@@ -1766,8 +1814,8 @@ In case one needs to explicitly specify some type parameters via [type arguments
1766
1814
1767
1815
An underscore type argument does not add any type information to the [constraint system][Kotlin type constraints] *besides the presence of a type parameter*, i.e., parameterized declaration with different number of type parameters could be distinguished by different number of underscore type arguments.
1768
1816
1769
-
If the type inference is successfull, each underscore type argument is considered to be equal to the inferred type for their respective type parameter.
1770
-
If the type inference is not successfull, it is a compile-time error.
1817
+
If the type inference is successful, each underscore type argument is considered to be equal to the inferred type for their respective type parameter.
1818
+
If the type inference is not successful, it is a compile-time error.
0 commit comments