Breaking changes
If we would summarise all implemented Swift 4 proposals, we would (as of 31–5–17,) come up with the following list.
The proposals that are highlighted in bold are proposals that introduce source breaking changes in Swift 4. Let’s dive deeper into each of these proposals.
Distinguish between single-tuple and multiple-argument function types”Š—”Š(SE-0110)
With this proposal, you now have to manually expand tuples from the now-single parameter. Let’s explain using a example.
typealias Name = (firstName: String, lastName: String) let names: [Name] = [("Bart", "den Hollander")]
// Swift 3 names.forEach({ first, last in print(last) // "den Hollander" })
The ‘first’ and ‘last’ variables are expanded from the tuple by the Swift 3 compiler. This is very helpful and readable.
Now let’s do the same within Swift 4.
// Swift 4 names.forEach({ first, last in print(last) }) // error: closure tuple parameter '(firstName: String, lastName: String)' does not support destructuring
The reason this doesn’t work anymore is because in Swift 4 you have to manually expand tuples from a single parameter. You can do the following to fix this.
// Swift 4 A: Expand by providing the tuple key names.forEach({ name in print(name.lastName) // "den Hollander" }) B: Expand by providing the amount of tuple elements in a variable names.forEach({ name in let (first, last) = name print(last) // "den Hollander" }) C: Change to a for loop for (first, last) in names { print(last) // "den Hollander" }
Still the question is raised as to why this change was introduced. This question is answered by Joe Groff, Swift Compiler Engineer at Apple.
The slushiness around arguments-as-tuples is one of the major sources of bad type checker performance.
— Joe Groff ⎷⃣ (@jckarter) May 25, 2017
I think that although this change may result in better type checker performance, this will lead to worse readability of the syntax.