How to Make Generic typealiases in Swift

Swift’s typealias declarations are a good way to clean up our code. It’s generally considered good practice in Swift to use typealiases to give more meaningful and domain-specific names to types that would otherwise be either too general-purpose or too long and complex. For example, the declaration:

typealias Username = String

gives a less vague name to the type String, since we’re going to be using strings as usernames and we want a more domain-relevant name for that type. Similarly, the declaration:

typealias IDMultimap = [Int: Set<Username>]

gives a name for [Int: Set<Username>] that is not only more meaningful, but somewhat shorter.

However, we run into problems when we want to do something a little more advanced; there is a possible application of typealias that Swift doesn’t let us make use of. Specifically, Swift doesn’t accept typealiases with generic parameters. If we try it the naïvely obvious way,

typealias Multimap<Key: Hashable, Value: Hashable> = [Key: Set<Value>]

we get an error at the begining of the type parameter list: Expected ‘=’ in typealias declaration. Swift (as of version 2.1, at least) doesn’t let us directly declare a generic typealias. This is quite a shame, as such an ability would be very useful in a lot of different contexts, and languages that have it (such as Rust, Haskell, Ocaml, F♯, or Scala) make use of it all the time, including in their standard libraries. Is there any way to work around this linguistic lack?

As it turns out, there is!

The Solution

It’s actually possible to effectively give a typealias type parameters, despite Swift appearing to disallow it. Here’s how we can trick Swift into accepting a generic typealias:

enum Multimap<Key: Hashable, Value: Hashable> {
   typealias T = [Key: Set<Value>]
}

The basic idea here is that we declare a generic enum whose sole purpose is to hold our (now technically non-generic) typealias as a member. We can then supply the enum with its type parameters and project out the actual typealias inside, like so:

let idMMap: Multimap<Int, Username>.T = [0: ["alexander", "bob"], 1: [], 2: ["christina"]]
func hasID0(user: Username) -> Bool {
    return idMMap[0]?.contains(user) ?? false
}

Notice that we used an enum rather than a struct; this is because an enum with no cases cannot have any instances (which is exactly what we want), but a struct with no members still has (at least) one instance, which breaks our layer of abstraction. We are essentially treating our caseless enum as a tiny generic module, within which everything (that is, just the typealias) has access to the Key and Value type parameters.

This pattern is used in at least a few libraries dedicated to functional programming in Swift, since such constructs are especially valuable there. Nonetheless, this is a broadly useful technique, and it’s the best method currently available for creating generic typealias in Swift.

The Applications

As sketched above, this technique works because Swift doesn’t object to an ordinary typealias nested inside a generic type declaration. However, it does object to multiple generic types being nested inside each other; it even objects to either a generic type being nested inside a non-generic type or a non-generic type being nested inside a generic type. As a result, type-level currying is not possible.

Despite this limitation, this kind of generic typealias is still useful for a lot of purposes; one big one is specialized error-return types, in which Swift can use this technique to imitate Rust’s standard library:

enum Result<V, E> {
    case Ok(V)
    case Err(E)
}
enum IO_Result<V> {
    typealias T = Result<V, ErrorType>
}

Another use for generic typealiases comes in the form of nested collections types:

enum DenseMatrix<Element> {
    typealias T = [[Element]]
}
enum FlatMatrix<Element> {
    typealias T = (width: Int, elements: [Element])
}
enum SparseMatrix<Element> {
    typealias T = [(x: Int, y: Int, value: Element)]
}

Finally, since Swift is a relatively young language, there are sure to be undiscovered applications for things like this; if you search, maybe you’ll find one!

Super-charge your Swift development by learning how to use the Flyweight pattern – Click here to read more

About the author

Alexander Altman (https://pthariensflame.wordpress.com) is a functional programming enthusiast who enjoys the mathematical and ergonomic aspects of programming language design. He’s been working with Swift since the language’s first public release, and he is one of the core contributors to the TypeLift (https://github.com/typelift) project.