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
Implicit member expressions now support chains of member accesses, making the following valid:
34
+
35
+
```swift
36
+
let milky: UIColor = .white.withAlphaComponent(0.5)
37
+
let milky2: UIColor = .init(named: "white")!.withAlphaComponent(0.5)
38
+
let milkyChance: UIColor?= .init(named: "white")?.withAlphaComponent(0.5)
39
+
```
40
+
41
+
As is the case with the existing implicit member expression syntax, the resulting type of the chain must be the same as the (implicit) base, so it is not well-formed to write:
42
+
43
+
```swift
44
+
let cgMilky: CGColor = .white.withAlphaComponent(0.5).cgColor
45
+
```
46
+
47
+
(Unless, of course, appropriate `white` and `withAlphaComponent` members were defined on `CGColor`.)
48
+
49
+
Members of a "chain" can be properties, method calls, subscript accesses, force unwraps, or optional chaining question marks. Furthermore, the type of each member along the chain is permitted to differ (again, as long as the base of the chain matches the resulting type) meaning the following successfully typechecks:
50
+
51
+
```swift
52
+
structFoo {
53
+
staticvar foo =Foo()
54
+
staticvar bar =Bar()
55
+
56
+
var anotherFoo: Foo { Foo() }
57
+
funcgetFoo() -> Foo { Foo() }
58
+
var optionalFoo: Foo? { Foo() }
59
+
subscript() -> Foo { Foo() }
60
+
}
61
+
62
+
structBar {
63
+
var anotherFoo =Foo()
64
+
}
65
+
66
+
let _: Foo?= .bar.anotherFoo.getFoo().optionalFoo?.optionalFoo![]
Copy file name to clipboardExpand all lines: docs/Branches.md
+7-7
Original file line number
Diff line number
Diff line change
@@ -18,11 +18,11 @@ To switch from one set of branches to another, you can use `utils/update-checkou
18
18
19
19
## The Release Branches
20
20
21
-
| Swift | LLVM Project
22
-
| ---------------- | ----------------------
23
-
| swift-x.y-branch | swift/swift-x.y-branch
21
+
| Swift | LLVM Project
22
+
| ----------- | -----------------
23
+
| release/x.y | swift/release/x.y
24
24
25
-
At some point before a release, a *release branch* will be created in every repository with a name like `swift-4.0-branch`. (The actual number is chosen by Apple.) After the branch has been created, commits must make it to this branch to make it into the release. In some cases, the [release manager][] for the branch will decide to merge in all additional changes from `master`; otherwise, cherry-picking changes and making a new pull request is the way to go. If there are any "patch" releases (e.g. Swift 4.0.1), they will also come from this branch.
25
+
At some point before a release, a *release branch* will be created in every repository with a name like `release/5.3`. (The actual number is chosen by Apple.) After the branch has been created, commits must make it to this branch to make it into the release. In some cases, the [release manager][] for the branch will decide to merge in all additional changes from `master`; otherwise, cherry-picking changes and making a new pull request is the way to go. If there are any "patch" releases (e.g. Swift 5.3.1), they will also come from this branch.
26
26
27
27
Note that these branches come not from the "development" branches (above), but the "upstream" branches (below). This is because they need to contain the latest changes not just from Swift, but from the LLVM project as well. For some releases, the release branch for the LLVM project will be timed to coincide with the corresponding llvm.org release branch.
28
28
@@ -35,7 +35,7 @@ Note that these branches come not from the "development" branches (above), but t
35
35
36
36
`swift/master-next` is a branch for LLVM that includes all changes necessary to support Swift. Changes from llvm.org's master branch are automatically merged in. Why isn't this just `swift/master`? Well, because LLVM changes *very* rapidly, and that wouldn't be very stable. However, we do want to make sure the Swift stuff keeps working.
37
37
38
-
If you are making changes to LLVM to support Swift, you'll probably need to work on them in `swift/master` to test them against Swift itself, but they should be committed to `swift/master-next`, and cherry-picked to the current release branch (`swift/swift-x.y-branch`) if needed. Remember, the release branches are automerged into `swift/master` on a regular basis.
38
+
If you are making changes to LLVM to support Swift, you'll probably need to work on them in `swift/master` to test them against Swift itself, but they should be committed to `swift/master-next`, and cherry-picked to the current release branch (`swift/release/x.y`) if needed. Remember, the release branches are automerged into `swift/master` on a regular basis.
39
39
40
40
(If you're making changes to LLVM Project that *aren't* about Swift, they should generally be made on llvm.org instead, then cherry-picked to the active release branch or `swift/master`.)
41
41
@@ -83,6 +83,6 @@ Some branches are *automerged* into other branches, to keep them in sync. This i
83
83
-`master` is automerged into `master-next`
84
84
85
85
### LLVM Project
86
-
-`swift/swift-x.y-branch` (the *latest* release branch) is automerged into `swift/master`
86
+
-`swift/release/x.y` (the *latest* release branch) is automerged into `swift/master`
87
87
- llvm.org's `master` is automerged into `swift/master-next`
88
-
- llvm.org's release branch *may* be automerged into `swift/swift-x.y-branch`, if they are in sync
88
+
- llvm.org's release branch *may* be automerged into `swift/release/x.y`, if they are in sync
0 commit comments