03: Source Stability (What is a Source Breaking Change?)
20 March 2017
Every Swift developer who has migrated code bases from Swift 1.x to 2.x, or even the more tedious 2.x to 3.x knows the pain of migrating to new Swift versions.
In this episode, we cover:
What is a source breaking change?
Almost guaranteeing that code that compiles with Swift 3.0 continues to compile with Swift 3.x and even Swift 4.x in Swift 3 mode. Why almost? Because it may be best to prevent code that never should have compiled with Swift 3.0 (i.e. compiled due to egregious bugs in the compiler) from compiling as those bugs are fixed. There are times when breaking compilation is preferable to continuing to exploit Swift bugs.
“we should try to get the “rearrange all the deckchairs” changes into Swift 3 if possible, to make Swift 3 to 4 as smooth as possible”: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007737.html
Community-driven breakage ;)
Slava Pestov (@slava_pestov) found and fixed a ‘horrific’ Swift 3 compatibility bug. When they say Swift 3.1 will be compatible with Swift 3, they’re serious. 😅
Tanner Nelson was behind the Type.self proposal, not Erica Sadun: https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md