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
+118-2Lines changed: 118 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,120 @@ _**Note:** This is in reverse chronological order, so newer entries are added to
5
5
6
6
## Swift 5.7
7
7
8
+
*[SE-0326][]:
9
+
10
+
It's now possible to infer parameter and result types from the body of a multi-statement
11
+
closure. The distinction between single- and multi-statement closures has been removed.
12
+
13
+
Use of closures becomes less cumbersome by removing the need to constantly specify explicit
14
+
closure types which sometimes could be pretty large e.g. when there are multiple parameters
15
+
or a complex tuple result type.
16
+
17
+
For example:
18
+
19
+
```swift
20
+
funcmap<T>(fn: (Int) -> T) -> T {
21
+
returnfn(42)
22
+
}
23
+
24
+
funccomputeResult<U: BinaryInteger>(_: U) -> U { /* processing */ }
25
+
26
+
let_=map {
27
+
iflet$0<0 {
28
+
// do some processing
29
+
}
30
+
31
+
returncomputeResult($0)
32
+
}
33
+
```
34
+
35
+
The result type of `map` can now be inferred from the body of the trailing closure
36
+
passed as an argument.
37
+
38
+
*[SE-0345][]:
39
+
40
+
It is now possible to unwrap optional variables with a shorthand syntax that
41
+
shadows the existing declaration. For example, the following:
42
+
43
+
```swift
44
+
let foo: String?="hello world"
45
+
46
+
iflet foo {
47
+
print(foo) // prints "hello world"
48
+
}
49
+
```
50
+
51
+
is equivalent to:
52
+
53
+
```swift
54
+
let foo: String?="hello world"
55
+
56
+
iflet foo = foo {
57
+
print(foo) // prints "hello world"
58
+
}
59
+
```
60
+
61
+
*[SE-0340][]:
62
+
63
+
It is now possible to make declarations unavailable from use in asynchronous
64
+
contexts with the `@available(*, noasync)` attribute.
65
+
66
+
This is to protect the consumers of an API against undefined behavior that can
67
+
occur when the API uses thread-local storage, or encourages using thread-local
68
+
storage, across suspension points, or protect developers against holding locks
69
+
across suspension points which may lead to undefined behavior, priority
70
+
inversions, or deadlocks.
71
+
72
+
*[SE-0343][]:
73
+
74
+
Top-level scripts support asynchronous calls.
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`.
80
+
81
+
Note that the transition affects function overload resolution and starts an
82
+
implicit run loop to drive the concurrency machinery.
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.
88
+
89
+
*[SE-0336][]:
90
+
91
+
It is now possible to declare `distributed actor` and `distributed func`s inside of them.
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
100
+
101
+
distributedfuncgreet(name: String) ->String {
102
+
greetingsSent +=1
103
+
return"Hello, \(name)!"
104
+
}
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
+
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
+
8
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.
9
120
10
-
For example, Swift 5.6 would allow the following code, which at runtime would construct an instanec 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:
11
122
12
123
```swift
13
124
protocolP {
@@ -49,7 +160,7 @@ For example, Swift 5.6 would allow the following code, which at runtime would co
49
160
50
161
*[SE-0341][]:
51
162
52
-
Opaque types can now be used in the parameters of functions and subscripts, wher they provide a shorthand syntax for the introduction of a generic parameter. For example, the following:
163
+
Opaque types can now be used in the parameters of functions and subscripts, when they provide a shorthand syntax for the introduction of a generic parameter. For example, the following:
53
164
54
165
```swift
55
166
funchorizontal(_v1: some View, _v2: some View) ->some View {
"If non-empty, when embedding the LLVM bitcode binary sections into the relevant binaries, pass in -bitcode_hide_symbols. Does nothing if SWIFT_EMBED_BITCODE_SECTION is set to false."
0 commit comments