Welcome to issue #100! 🎉As you’ve probably heard by now, this will be the final issue of the newsletter. I encourage you to read my entire blog post announcement, but here’s the TL;DR: it’s time for me to focus on other projects and priorities, and if possible, transition the newsletter to a new owner. Luckily, the project is extremely healthy and could easily be taken over by an eager and motivated member of the community. If you are interested, please get in touch!

This newsletter started out as an accident. It began on my personal blog before I decided to create this site and start the mailing list. Two years later, here we are. It’s been a pleasure to deliver an issue to your inbox each week. The good news is that I’ll still be bringing you Swift news regularly — in podcast form with the one and only JP Simard. If you haven’t subscribed, you should do it now. 😄 I’ll also continue to write about Swift on my blog. Of course, there are many other fantastic blogs to follow in the Swift community, which I’ve linked to often — so there will be no shortage of content for sure! My hope is that the new Swift forums, which should be rolled out soon, will help make following Swift evolution and other Swift.org news easier without this newsletter.

Alright — let’s get on with our last issue!

News and community

Daniel Duan made a YouTube video tutorial on how to contribute to open source Swift. In the video he discovers, reports, fixes, and merges a bug in corelibs-foundation. 🤓 📺

Ole Begemann wrote two posts, A hack for fixed-size arrays and a follow-up post on how Swift imports C arrays as tuples. They provide an interesting look at what it currently takes to create a fixed-size array in Swift — and the cost of doing it.

objc.io wrote a post on implementing weak arrays in Swift. It’s an interesting idea, and they apply this in one of their Swift Talk episodes.

Commits and pull requests

Doug Gregor merged improves to the type checker for 4.1 to make redeclaration checking validate fewer declarations. This fixes SR-6558.

Gregory Williams fixed a crash in CharacterSet, resolving SR-2988.

Chris Lattner merged changes to reduce Swift array literal abstraction penalties, that is, to make the SIL optimizer able to eliminate bridging overhead when dealing with array literals from Objective-C. In the test example, this results in 4x less SIL code.

Slava Pestov continued his work on class resilience with part 10, part 11, and part 12.

Roman Roibu merged a new IDE refactoring, expand a ternary operator into an if statement and vice-versa.

David Zarzycki warmed Slava’s heart 😄 by cleaning up some technical debt in SIL.

Proposals

No updates on proposals this week, likely because of the holidays. Check the status page for updates!

Mailing lists

Discussion on the swift-evolution list this week continued to center around SE-0192: Non-Exhaustive Enums. Jordan Rose will be incorporating feedback into a revision of the proposal:

Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems that most people seem to like @frozen, and that does in fact have the connotations we want it to have. I like it too.

More seriously, this discussion has convinced me that it’s worth including what the proposal discusses as a ‘future’ case. The key point that swayed me is that this can produce a warning when the switch is missing a case rather than an error, which both provides the necessary compiler feedback to update your code and allows your dependencies to continue compiling when you update to a newer SDK. I know people on both sides won’t be 100% satisfied with this, but does it seem like a reasonable compromise?

The next question is how to spell it. I’m leaning towards unexpected case:, which (a) is backwards-compatible, and (b) also handles “private cases”, either the fake kind that you can do in C (as described in the proposal), or some real feature we might add to Swift some day. unknown case: isn’t bad either.

I too would like to just do unknown: or unexpected: but that’s technically a source-breaking change:

switch foo {
case bar:
  unknown:
  while baz() {
    while garply() {
      if quux() {
        break unknown
      }
    }
  }
}

Another downside of the unexpected case: spelling is that it doesn’t work as part of a larger pattern. I don’t have a good answer for that one, but perhaps it’s acceptable for now.

I’ll write up a revision of the proposal soon and make sure the core team gets my recommendation when they discuss the results of the review.

I’ll respond to a few of the more intricate discussions tomorrow, including the syntax of putting a new declaration inside the enum rather than outside. Thank you again, everyone, and happy new year!

Finally

And finally — thank you for reading. I cannot say ‘thank you’ enough. Thanks for reading these issues over the past two years. Thanks to all of the fantastic sponsors that helped motivate and incentivize me to keep writing. And thanks to the other great writers who wrote issues so that I could take much-needed breaks: Brian Gesiak, JP Simard, Bas Broek, Greg Heo, Ben Asher, Garric Nahapetian, and Roman Volkov.

This is the final “finally”, at least for awhile. Until next time.
—jsq