03: Source Stability (What is a Source Breaking Change?)

Swift Unwrapped

Content provided by Spec Network, Inc., JP Simard, and Jesse Squires. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Spec Network, Inc., JP Simard, and Jesse Squires or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

9y ago 29:39

MP3•Episode home

Archived series ("Inactive feed" status)

When? This feed was archived on February 06, 2022 00:51 (4y ago). Last successful fetch was on June 23, 2021 01:36 (4+ y ago)

Why? Inactive feed status. Our servers were unable to retrieve a valid podcast feed for a sustained period.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

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. 😅

Dollar Sign
- https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
Swift Weekly
- Issue 39, https://swiftweekly.github.io/issue-39/
  - Slava Pestov changed variadic closure arguments to be @escaping by default, which is technically a source breaking change, but only for invalid code.
- Issue 42, https://swiftweekly.github.io/issue-42/
  - Robert Widmann merged changes to reject standalone $ as identifiers, which were accidentally accepted as valid.
- Issue 43, https://swiftweekly.github.io/issue-43/
  - Rintaro Ishizaki has submitted a pull request to fix SR-2843. In type parsing, P1 & P2.Type (new protocol syntax) was incorrect.
  - DougGregor fixed an unintentional source-breaking change from Swift 3 regarding implicitly-unwrapped optionals and type inference.
Minor source breaking change for sugared types: https://github.com/apple/swift/commit/4ebac86895383ad15e34de3671c6f423e96cfc98
Running the entire test suite with version 3 or 4: https://github.com/apple/swift/commit/1fcd7d725d1c23a27d4ea31e34e20f182e0b8c37
Ignored Labels for single-"Any"-argument functions
- https://github.com/apple/swift/commit/30c4235193b64050f8110ef5598c7efb4501e0da
Xcode 8.2 last release for Swift 2.3!

Errata:

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

93 episodes