Here we are again with another monthly summary of Swift Evolution. July was a very special month for me, so I’d like to start with two topics that are important to me personally. I hope you’ll excuse that — but both are still on-topic:
Firstly, my very first app as an Indie Developer, which I’ve been working on for six months now, is finally done and in Open Beta
! It’s an app for Swift developers and improves the localization workflow
in Xcode. In the first version, among other things, you can add new localized keys to your projects in multiple languages without ever leaving your Swift file and safely reference them in code — just by filling out a single form! The app will take care of adding entries to all the right files and even optionally machine-translate to multiple languages, see this GIF:
If this looks interesting to you, please try the beta
and send me your feedback.
Secondly, one day after sending out the previous issue of this newsletter, I wrote my very first own Swift Evolution pitch
. In the thread, I’m requesting a new syntax to improve the usage of the
type as an alternative for Swift’s native error handling. In the above-mentioned app project, I preferred to have typed errors in order to vastly improve my error handling experience by forcing me to handle all possible error cases with a useful message. But Swift currently doesn’t support typed throws, so I used
instead and migrated all my throwing functions in the above-mentioned app to it. I’ll be writing about my approach in detail soon on my dev blog
if you’re interested. But I came across two safety & convenience issues that I couldn’t fix without changes in the language itself. Thus, the pitch
If my pitch sounds like something you’d want to have in Swift, don’t get too excited though. Even though I tried to scope it clearly and I tried to make the change as small and language-fitting as possible, I quickly received a lot of refusing comments due to historical discussions on typed
throws, even though my pitch is just about adding convenience & safety to
Result – to improve things already possible in Swift today. In fact, the topic of typed
throws seems to be one of the most controversial topics on Swift Evolution, which I learned the hard way in this thread. This was not the great first-pitch experience on Swift Evolution that I was hoping for to write about in this issue of the newsletter.
Thankfully, after explaining my specific use case
and clarifying that my intention was not to rehash any historical discussions
, the topic of the thread changed from a judging “there’s no problem in the language, you’re just using it wrong” to a more accepting “let’s explore how we can improve the valid use case you described” kind of vibe. I hope it stays like that and even more, I wish it was like that from the start. It’s hard for me to motivate anyone in the developer community to be more active in the forums with their own pitches if I have to add to that that they should be cautious not to run into some of the difficult topics. But here we are.
I’m sure, the whole thing was a misunderstanding and I probably didn’t communicate things clearly enough on my end. But in any case, this is a good opportunity to remind everyone (including me!) to always initially expect others to have good intentions and to respect the decisions they made for themselves. This is much better than expecting the worst and judging their decisions by making assumptions about their situation based on your own past experiences. It might be tempting to do that sometimes as it can simplify your life, but it’s not always right and can even hurt people. After all, people are different, situations are different, therefore solutions will always be different, too. A “general purpose language” like Swift and the community around it should accommodate that.
With this longer comment this time, let’s get on to this month’s proposals!