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: CHANGELOG.md
+52-52Lines changed: 52 additions & 52 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,54 +71,54 @@ _**Note:** This is in reverse chronological order, so newer entries are added to
71
71
72
72
*[SE-0343][]:
73
73
74
-
Top-level scripts support asynchronous calls.
74
+
Top-level scripts support asynchronous calls.
75
75
76
-
Using an `await` by calling an asynchronous function or accessing an isolated
77
-
variable transitions the top-level to an asynchronous context. As an
78
-
asynchronous context, top-level variables are `@MainActor`-isolated and the
79
-
top-level is run on the `@MainActor`.
76
+
Using an `await` by calling an asynchronous function or accessing an isolated
77
+
variable transitions the top-level to an asynchronous context. As an
78
+
asynchronous context, top-level variables are `@MainActor`-isolated and the
79
+
top-level is run on the `@MainActor`.
80
80
81
-
Note that the transition affects function overload resolution and starts an
82
-
implicit run loop to drive the concurrency machinery.
81
+
Note that the transition affects function overload resolution and starts an
82
+
implicit run loop to drive the concurrency machinery.
83
83
84
-
Unmodified scripts are not affected by this change unless `-warn-concurrency` is
85
-
passed to the compiler invocation. With `-warn-concurrency`, variables in the
86
-
top-level are isolated to the main actor and the top-level context is isolated
87
-
to the main actor, but is not an asynchronous context.
84
+
Unmodified scripts are not affected by this change unless `-warn-concurrency` is
85
+
passed to the compiler invocation. With `-warn-concurrency`, variables in the
86
+
top-level are isolated to the main actor and the top-level context is isolated
87
+
to the main actor, but is not an asynchronous context.
88
88
89
89
*[SE-0336][]:
90
90
91
-
It is now possible to declare `distributed actor` and `distributed func`s inside of them.
91
+
It is now possible to declare `distributed actor` and `distributed func`s inside of them.
92
92
93
-
Distributed actors provide stronger isolation guarantees than "local" actors, and enable additional checks to be made on return types and parameters of distributed methods, e.g. checking if they conform to `Codable`. Distributed methods can be called on "remote" references of distributed actors, turning those invocations into remote procedure calls, by means of pluggable and user extensible distributed actor system implementations.
94
-
95
-
Swift does not provide any specific distributed actor system by itself, however, packages in the ecosystem fulfil the role of providing those implementations.
96
-
97
-
```swift
98
-
distributedactorGreeter {
99
-
var greetingsSent =0
93
+
Distributed actors provide stronger isolation guarantees than "local" actors, and enable additional checks to be made on return types and parameters of distributed methods, e.g. checking if they conform to `Codable`. Distributed methods can be called on "remote" references of distributed actors, turning those invocations into remote procedure calls, by means of pluggable and user extensible distributed actor system implementations.
94
+
95
+
Swift does not provide any specific distributed actor system by itself, however, packages in the ecosystem fulfil the role of providing those implementations.
100
96
101
-
distributedfuncgreet(name: String) ->String {
102
-
greetingsSent +=1
103
-
return"Hello, \(name)!"
97
+
```swift
98
+
distributedactorGreeter {
99
+
var greetingsSent =0
100
+
101
+
distributedfuncgreet(name: String) ->String {
102
+
greetingsSent +=1
103
+
return"Hello, \(name)!"
104
+
}
104
105
}
105
-
}
106
-
107
-
functalkTo(greeter: Greeter) asyncthrows {
108
-
// isolation of distributed actors is stronger, it is impossible to refer to
109
-
// any stored properties of distributed actors from outside of them:
110
-
greeter.greetingsSent// distributed actor-isolated property 'name' can not be accessed from a non-isolated context
111
106
112
-
// remote calls are implicitly throwing and async,
113
-
// to account for the potential networking involved:
114
-
let greeting =tryawait greeter.greet(name: "Alice")
115
-
print(greeting) // Hello, Alice!
116
-
}
117
-
```
107
+
functalkTo(greeter: Greeter) asyncthrows {
108
+
// isolation of distributed actors is stronger, it is impossible to refer to
109
+
// any stored properties of distributed actors from outside of them:
110
+
greeter.greetingsSent// distributed actor-isolated property 'name' can not be accessed from a non-isolated context
111
+
112
+
// remote calls are implicitly throwing and async,
113
+
// to account for the potential networking involved:
114
+
let greeting =tryawait greeter.greet(name: "Alice")
115
+
print(greeting) // Hello, Alice!
116
+
}
117
+
```
118
118
119
119
* The compiler now emits a warning when a non-final class conforms to a protocol that imposes a same-type requirement between `Self` and an associated type. This is because such a requirement makes the conformance unsound for subclasses.
120
120
121
-
For example, Swift 5.6 would allow the following code, which at runtime would construct an instance of `C` and not `SubC` as expected:
121
+
For example, Swift 5.6 would allow the following code, which at runtime would construct an instance of `C` and not `SubC` as expected:
122
122
123
123
```swift
124
124
protocolP {
@@ -226,24 +226,24 @@ Swift 5.6
226
226
227
227
*[SE-0327][]:
228
228
229
-
In Swift 5 mode, a warning is now emitted if the default-value expression of an
230
-
instance-member property requires global-actor isolation. For example:
0 commit comments