It’s been just over two years since we first saw “Improving the UI of generics,” the discussion post about potential changes to make generic types easier to work with in Swift, and five years since the first version of the Swift Generics Manifesto. (Time flies when you’re building a language!) Last week, generics landed back in the spotlight, as Anthony Latsis, Filip Sakel, and Suyash Srijan proposed SE-0309, with a major change that addresses one of the most infamous errors in Swift:

Protocol can only be used as a generic constraint because it has ‘Self’ or associated type requirements.

While this change is still in review (through May 1), it looks very promising — but, as often happens when dealing with the corners of the type system, the details can be a bit opaque. Much like last time, this post will walk through the nitty-gritty of the proposed changes in SE-0309, and offer some practical scenarios where they might improve day-to-day Swift usage.

Well, I lasted all of a month on the first pass at an upgraded home office audio setup. While it was a huge step up from the previous, isolated, every-system-for-itself output configuration, there were just a few wrinkles that I wanted to address while I was in this headspace.

As is habitual when I undertake these kinds of projects, I found just a couple additional tweaks and hardware add-ons to do. I wouldn’t call the changes they made “solved problems,” per se — everything worked just fine beforehand — but I did get a few additional features and niceties that I’ve really enjoyed.

Two weeks after WWDC 2020, I’m still slowly soaking in the flood of new features, fixes, and info — only this time from home, with WWDC going virtual. Apple mentioned in their keynote that Messages traffic is up 40% in recent months, with folks largely confined to home, and I’m betting that videoconferencing is also up at least that much. I’ve certainly had more video calls in the last three months than I’d had in the prior three years.

On that note, I want to dig in to an upgrade I recently made to my home office audio setup, mostly for videoconferencing and gaming purposes. Fair warning: this is pretty different from other recent posts, where I delve into some quirk of Swift or an Apple framework. Instead, we’ll chat about pieces of audio equipment that are — I readily admit — way too powerful for solving the problem at hand. But then again, what fun is there to be had in a home improvement project that stops short at just barely meeting the requirements?

Like so many articles with leading titles, the answer to this one is simple: no, the idle timer still works fine. But that doesn’t mean we can’t have fun exploring a little along the way!

This topic came up while introducing support for iOS 13 application scenes to an existing app. This app supported back to iOS 11, and used the UIApplication property isIdleTimerDisabled shortly after launch to keep the phone awake as long as it was in the foreground.

After adding scene support, though, this stopped working. The app seemed to become subject to the idle timer again, with no discernible change in the code that disabled the timer in the first place. This post is the story of finding the problem, and the straightforward change that fixes it.

Earlier this week, Joe Groff of the Swift Core Team published a massive discussion post on the Swift forums. It discussed a lot of possible changes to the way that generics work in the Swift language, and kicked off the process with a link to SE-244, a proposal to introduce some features around function return values. The post as a whole was an absolutely fascinating read, and made a really compelling case for some powerful new ideas that might come to Swift.

In discussing this post with some colleagues, though, it’s become clear that the intended audience is a little more embedded into the theory and technical details of programming language evolution than your average Swift developer. There’s nothing wrong with that — it’s reassuring to know that the folks driving changes in Swift have a solid background in language design, and that they’re thinking about all manner of hard problems in order to make our lives easier. However, it makes me worry that people might be missing out on a truly exciting conversation about what might be coming in a future Swift version.

To that end, this post aims to walk through some of the proposals from Joe’s document, explaining the syntax and offering examples of how the changes to generics might look in practice. We’ll pick up a couple technical terms in a practical setting, and wrap up with some details about the open Swift Evolution proposal(s) being considered.