Swift Regrets
For the past few weeks I’ve been writing Twitter threads on “Swift regrets”, things I wish we’d done differently early on in Swift’s development. I’ve been doing them on Twitter rather than as blog posts because of my RSI—short-form on my phone is easier than long-form at a keyboard when I spend so much time on a keyboard for work. But I’m mirroring them here, lightly edited, so they don’t get lost in the eternal history of Twitter. You can find them under the Swift regrets tag.
I worked on Swift at Apple from pre-release to Swift 5.1. I’m at least partly responsible for many things people like about Swift and many things people hate about Swift. This list is something I started collecting around when I left Apple, and I’m putting them up so other language designers can learn from our mistakes. These are all things that would be hard to change in Swift today, because they’d break tons of people’s code. That’s what happens with real-world languages and libraries: the more users you have, the fewer breaking changes you can make.
That said, I don’t want people to think “oh, Jordan hates Swift” or “gosh, look at all these issues in Swift, why can’t they get it right”. That’s definitely not the takeaway here. I love Swift. Every language has warts, mistakes, compromises, I promise you. And a lot of what Swift did wasn’t new; it was borrowing and maybe improving on ideas from other languages. So future languages should improve on Swift, but also I decided to stir in “Swift delights”, things I want other languages to borrow. They’re not things only Swift does, but they are things I appreciate in Swift and that I’d like to see in future languages as well.
Obviously I expect people to disagree with me on many of these; heck, for many of them Past Me would disagree too, and that’s why things are the way they are! Also, please feel free to ask questions. (And if one interests you in particular, I suggest checking out the Twitter thread to see what other people added.)