Some would say that typealias in Swift is a hotly debated topic, I don’t know that I would fall into this group, but I would say that typealias initially comes with some confusion; and for me this was true for a long time. typealias is one of those things in Swift that I would call neat in the sense that it can be very helpful, it can also be misleading, and it can be excluded from your code completely without any major consequences. It’s really one of those tools that doesn’t have any hard and fast rules around when to use it, or even if it needs to be used. The primary function of typealias (and some may disagree with my simplification here) is syntax.
What is typealias?…
typealias is, for lack of a better term, a syntax helper in Swift. It allows you to provide a nickname for things. This could be a nickname for a closure, or a nickname for a set of protocols, or even a nickname for another type. For example…
In fact if you jump into Xcode and type out typealias autocomplete will give you the following…
So when should it be used?…
Well, in my opinion there are really no rules here per-say; it should be used when it helps to make sense of the code or helps to improve the structure of the code. For me this generally means that it meets one or many of the following conditions…
- It will reduce redundancy by providing a meaningful name for a common code structure
- It will help to improve not only the human readability, but also enable disambiguation of code
- It will replace potentially empty or excessive code structures
So let’s look at some examples that support these three ideas…
1: Reduce Redundancy…
Let’s say that we have a network service, and the call signature of every method takes the same closure. With typealias, we might be able to improve the syntax of these signatures by not only simplifying them, but also by providing a name for the return closure that is more descriptive of the return type than just the closure itself, and of course we can then reduce the literal amount of code that we have to wright.
Without typealias, our class might look like this…
First, there really isn’t anything inherently wrong with the code above, but it is pretty verbose in that every method signature has the same lengthy closure. Also, at a call site what we see might be less intuitive…maybe…
Now let’s look at the same class but with a typealias.
So simply put, we give the closure a nickname ResultWithOptionalError and then replace it in the method signatures with this more “descriptive” value. Now at our call sites we see the ResultWithOptionalError typealias instead of the more verbose standard closure syntax. But is this better? Well, the jury really is still out on that. I think that arguments could be made either way. The obvious pros here are that this is a bit cleaner, and its for sure more “human readable”. But on the other side, it adds a layer of obfuscation to what ResultWithOptionalError actually is. A developer can of course either use option + click to expose this in Xcode or track down the declaration, but it’s still an extra step. I think however that this could also be a good argument for inline documentation, which I am in fact a big fan of, but thats not the point of this blog post.
2: Improve human readability and support disambiguation…
In some cases using the literal type in a method signature can actual lead to more confusion. Using a typealias might help us to add some clarity to the the signature. Consider the following example which provides a helper method to be used on ViewController to present an alert view…
In this case a developer might be a little confused by this call signature, maybe you see this and you wonder “why would I need a string, I thought this was an alert view?”. We might be able to improve this using a typealias.
Now, the call site is explicit in declaring what the string is for. Again, there can be many arguments made about this. It’s great because from the human readable perspective the call site is very clear. We know that we need to provide an AlertMessage. This could be very helpful especially to a new developer on a project. However, I can also see some issues where this acts like a double edge sword. I might in fact be more confused as I don’t necessarily know that an AlertMessage is just a string. And furthermore I think the argument could be made that a simple improvement to the method signature itself would have the same effect.
3: Replace potentially empty or excessive code structures…
Last, let’s look at a case where typealiasing helps us to remove somewhat wasteful code structures. Assume we have a set of protocols, and they define two sets of potentially related behavior…
Sometimes we need to conform to Driveable only, because really we are only concerned with our object doing those things as they are related to being a Driveable object. On the other had sometimes we only need our object to be Parkable. But what if we have a case where we want to our object to be both Parkable and Driveable? We could have our object conform to both…
And really this is fine, but what if for clarity and reduced code length maybe we wanted this to be its own type? We could just create an empty protocol…
But this is kinda gross because now we have this empty protocol laying around that really doesn’t do anything other than marry our Driveable and Parkable protocols, and that isn’t actually what protocols are for. With typealias however, we can accomplish this same desired outcome in a very Swifty AND not so smelly way…
Now we don’t have an empty protocol, instead we have nice clean code, and we have the ability to conform to either Driveable, Parkable or both! In fact Apple uses this exact implementation in their Codeable type, check it out here.
In this case I don’t actually have any real cons, I think this is in fact the perfect used of the typealias tool!
Wrapping up…
So is typealias revolutionary? Probably not, but it is another pretty nifty arrow to add to your Swift quiver. It can help to make code clear and easy to work in, but it also have have the opposite effect by obfuscating things or adding additional complexity. Should you use it? I think that really is up to you, your team, and the standards of your code based, but hopefully at the very least if you had some confusion around this tool I have helped to add some clarity, and as always, from my position explaining a topic is the best road to mastery and that in fact is one of the goals of my technical blogging.
Until next time …
Dining With Robots 