Swift: What are Protocols with Associated Types?

I recently gave a talk about Protocols with Associated Types (PATs) – I was worried that my audience would already know everything about PATs, but turns out the opposite is true.

Many didn’t know what PATs were – which I should have anticipated in hindsight, since it took me a while to learn about them myself. So I wanted to explain them right here, especially since they are challenging to understand and there aren’t that many great explanations that I’ve found.

The best explanation that really helped me was by Gwendolyn Weston at the try! Swift conference in Tokyo (video here), so the example is inspired by her talk. There will be Pokemon…

Before PATs

I’m currently Level 9 in Pokemon Go, and I learned (thanks to my personal trainer @ayanonagon) that all Pokemon have some common traits, such as the power to attack.

Coming from Objective-C or other object-oriented languages, it might be tempting to have a Pokemon subclass for all the common functionality. Since each Pokemon attacks with a different power – lightning or water or fire, etc – we can use the power of Generics in our subclass:

At this point, we would have different Powers modeled:

Now, other Pokemon can subclass from our base Pokemon class, and they will automatically have the attack function!

The problem here is that we’re subclassing. If you’ve watched Dave Abrahams’ WWDC talk on Protocol-Oriented Programming in Swift, you should be seeing the face of Crusty in your head right now…

The problem with subclassing is that while it starts out with great intentions, eventually things get a lot messier as exceptions arise (e.g. Pokemon Eggs can’t attack). I highly recommend reading Matthijs Hollemans’s Mixins and Traits in Swift 2.0 to understand this more.

After all, as Dave Abrahams stated, Swift is a Protocol-Oriented Language, so we need to change our Object-Oriented mindset…

Hello, PATs

Instead of subclassing, let’s do the same thing with PATs! Instead of subclassing all the things, we can create a Protocol that focuses on the Pokemon’s ability to attack. Remember, since each Pokemon has a different Power, we need to make that a Generic:

Now, any Pokemon that conforms to the PowerTrait protocols will have the attack functionality no subclassing necessary!


That’s it! A protocol with associated type is just a fancy term to a protocol that has generics in it. By using PATs (and protocols in general), we have a powerful tool that promotes really nice composition in favor of messy inheritance.

To learn more about the limitations of PATs and go deeper, I highly recommend Alexis Gallagher’s talk here.

Happy catching!

Join me for a Swift Community Celebration 🎉 in New York City on September 1st and 2nd. Use code NATASHATHEROBOT to get $100 off!

Enjoy the article? Join over 17,500+ Swift developers and enthusiasts who get my weekly updates.

  • 马权

    how about this, maybe not need struct pikachu:

    struct AnyPokemon: PowerTrait {
    typealias Power = P

    let pikachu = AnyPokemon()


    • I think that the point in using PATs is to avoid creating generic structs/classes or at least the declaration of them. The PATs associatedType themselves are providing a way to assign generic properties without forcing the declarative signatures into your struct/class definitions. I’m still trying to wrap my head around PATs so I may have missed something. If so, please let me know.

  • Artem Sherbachuk

    finally i got that associatedtype is the same as typealias, I need more read swift evolution. Thanks! Great Post!

  • Steve

    There’s an error in the code. To specify the associated type inside the struct you still have to say typealias rather than associatedtype. So, associatedtype Power = 🌩 should read typealias Power = 🌩