Swift Typed Throws compared with Rust

I was reading about Error Handling in Rust to have a better understanding of the implications of typed throws in Swift (thanks to David for the proposal). At the end of that guide there is an example using a simple script to search for the population of a city in a CSV. This are my conclusions after porting that script to Swift.

You can see the script in GitHub.

I can see how having specific types declared when throwing errors would be really useful. I’ve been of that opinion since Swift 2, but I also can see the need to improve the throwing mechanisms to have something like Rust (try! and From).

This will allow the conversion and propagation of errors from one layer to another almost automatically. Without this, we are gonna end repeating conversion code all over the place, unless we come up with better solutions. (David has already proposed some in the mailing list)

One point that I want to make is the difference between Result and throws. Although both are practically the same, the reality is that the throws system introduces a completely different way of dealing with errors and Result doesn’t. The fact that for simple domain errors we use Optional but for recoverable errors we have to use throws instead of Result introduces a discrepancy that I’ve noticed while writing code with different kinds of errors.

That said, the first step is having typed throws. We can come up with solutions with practice and experience and keep improving the language. And, the best part is that, if people doesn’t want work with errors of a specific type they can always fallback to catch everything or not specify the type in the function declaration.

Scripts in Swift

Doing this little exercise also allowed me to play again with scripts in Swift, and sadly I have to say that it’s still not there.

The setup is not as easy as it should be. Granted, Cocoapods and Rome help a lot, but you still have to specify the dependencies in the script itself in order to load the frameworks. I hope that SPM solves this at some point.

For me personally, it’s also a pain point not having an easy way to have autocompletion. Having to create and Xcode project and import the frameworks has a lot of friction. With Swift being open source I hope that simpler editors like Atom can fix this.

Swift as scripting language

Using Swift from scripts to low level systems and not only for Apps is one of the most exciting things about the language. Leaving aside the difficulties about making scripts in Swift, let ma talk about the ability of the language itself to make them.

Looking at the above points, the majority of time has been spend in the setup of the project and dependencies and also the decoding from the CSV to the structs.

Apart form this, the rest, the true part of the time dedicated to write the script, is not more painful or slower that in any other language. I would even say that having the compiler detecting problems for you makes it so much easier and better.

As is shown in the script, or just following the Rust error page, you can just ignore all the errors with try! or force unwrapping the optionals, that’s not different from writing with any other scripting language.

The huge difference is that when you are ready to convert the code to something more stable, the compiler is there to help you.

Remember to check David’s proposal and give your opinion on typed throws.