Swift.org blog: Library Evolution in Swift

[Nevin]

Typos

Swift 5.1 shipped with two new features related to binary stability that enables binary frameworks that can be distributed and shared with others:

Should be “enable”.

(And as a style point, it probably reads better if the first “that” becomes “, which”.)

• • •

A switch over a frozen enum is considered exhaustive if all cases are covered by the switch, whereas a switch over a non-exhaustive enum must always provide a default or @unknown case.

I believe “non-exhaustive” should be “non-frozen”.

• • •

This means that clients normally importing the framework remains binary compatible with a new version built for testing.

I’m not entirely sure what needs to change, but the grammar seems off here. It might be as simple as turning “remains” into “remain”, or “clients” into “a client”.

• • •

This ensures that while library evolution support can increase code size, it does impact the cache locality of data.

I suspect there’s supposed to be a “not” in there somewhere.

• • •

Currently its existence is an implementation detail, but a pitch to add modify accessors to the language is currently making its way through the Swift evolution process.

The second occurrence of “currently” seems redundant.

Formatting

The code-coloring of “associatedtype” in the blog post is weird. The first two letters are pink, while the rest of the word is black. It ought to be all pink since it’s a keyword.

• • •

The first occurrence of the Temperature example has all the lines of code indented by 2 extra spaces. (The other code examples don’t.)

• • •

I’m a bit confused the by Temperature example:

  public struct Temperature {
    public var celsius: Int
    public var fahrenheit: Int {
      get { (celsius * 9) / 5 + 32 }
      set { celsius = ((newValue - 32) * 5) / 9 }
    }
  }

The implementation of a public declaration can be changed, as long as the new implementation is compatible with existing expected behavior. For example, a function’s body might be replaced with a more efficient algorithm producing the same result. Or, a stored property can be changed into a computed property, as long as the computed property has the same observed behavior.

For example, the following implementation of Temperature is binary compatible with the one we saw earlier:

public struct Temperature {
  public var celsius: Int {
    get { ((fahrenheit - 32) * 5) / 9 }
    set { fahrenheit = (newValue * 9) / 5 + 32 }
  }
  public var fahrenheit: Int
}

Assuming we have a var t: Temperature, with the first version:

t.celsius = 2
print(t.celsius)  // “2”

But with the second version:

t.celsius = 2
print(t.celsius)  // “1”

Is this kind of observable behavior change really permitted?

• • •

I also have a general question:

• A superclass can be inserted between two existing classes.

• Changes to a protocol’s list of refined protocols are not allowed.

What’s the difference between a class hierarchy and a protocol hierarchy, which makes it possible to resiliently insert a new class into the middle of an existing hierarchy, but not possible to insert a new protocol into the middle of an existing hierarchy?

• • •

Finally, the blog post says:

An important concept is a resilience boundary .

But it never provides an actual definition for what that term means. After introducing the term, the text makes use of it repeatedly when listing things that do and don’t work across a resilience boundary, yet there is no clear explanation of where such a boundary is found.