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.

Of the several lingering rumors around Apple’s hardware strategy, there are two that tend to rise to the top:

• Will there be ARM Macs, and
• Where’s my new Mac Pro?

Often we think of these separately. ARM chips have been the backbone of phones and tablets for some time, but that’s obviously the slot they’ll stay in. If a Mac were to be ARM-based, it’d be the MacBook Air or something equally lightweight, both in pounds and in power — the Mac Pro wouldn’t enter into the equation at all.

The debugDescription property has been around for quite awhile. Formally first appearing as a @property on NSObject in iOS 5 and macOS 10.8, it came across into Swift as a member of the CustomDebugStringConvertible protocol, and continues to be incredibly useful today.

But somehow it still manages to surprise me when I find a detailed custom implementation of the property, like the one I just discovered on NSNotificationCenter.

As Swift enters its fourth year in public and continues to evolve, it becomes more and more attractive to add new features using the language — but for those of us who are blessed with large legacy codebases, crossing the divide between Objective-C and Swift can be a burden. What’s more, some of the language features in Objective-C that can help ease this transition aren’t necessarily well-documented or publicized.

This is an issue I’ve been grappling with in different projects for some time, and so when the opportunity arose to discuss the topic at our local Xcoders meetup, I took it. I think this talk had the fewest slides of any presentation I’ve ever given, so I won’t reproduce them here, but the example project is available on GitHub — both before and after the changes from the talk. You can also find a video of the talk on Vimeo.

Toying around with some code on the bus this morning, I came across an interesting fact about region flag emoji. Among the thousands of emoji that the Unicode standard defines, 270 of them represent region flags, each corresponding to a two-character region code: “us” means 🇺🇸, for example.

My curiosity was this: is there a way to programmatically generate the flag emoji 🇺🇸 from the string "us"? I was afraid that, like many other emoji, the flags would each have a unique name — something like REGIONAL FLAG UNITED STATES — and would require a lookup table to translate between the basic string "us" and the resulting emoji. Not so!