Generic Swift: It Isn’t Supposed to Hurt - Rob Napier

ChariotSolutions · 7K views · 2019 · 58:16

Open on YouTube

Programming language designSoftware architecture & designtalk

Why Stack Overflow recommends it

Stack Overflow users link it when answering questions about Swift protocols, associated types, and Equatable across class hierarchies or arrays of protocol types.

Recommended by 2 people across 2 different months, 2022 to 2025.

What it is

A conference talk from Philly ETE 2019 in which Rob Napier explains how to write generic Swift without fighting the compiler. It covers protocols with associated types, type erasers, Any, enums with associated data and closures, and when each tool fits.

What people said

Recommends Bulat Yakupov · 2022-10 · Stack Overflow · on “swift generic constraint type is also a return type”

You can make build() function generic or use typecasting. Anyway this two ways determine concrete type outside of method not inside. So first of all you need to remove associatedtype . If you specify associated type Output it means that the implementation of your Builder protocol should return some concrete type which conforms to MyProtocol . If you want your Builder to return any type which conforms to MyProtocol not the concrete one specified for this implementation of Builder then you shouldn't declare any associated types. Let's see how type casting can work: protocol Builder { func build() -> MyProtocol? } struct ABuilder: Builder { func build() -> MyProtocol? { // some code } } let bui

Recommends Alexander · 2025-05 · Stack Overflow · on “How to properly implement the Equatable protocol in a class hierarchy?”

This is a little tricky because Equatable does not just mean "has an equals operator". It's specifically expressing substitutability, that if two objects are equal, the two are completely interchangable. E.g. if you put them both in a set, only one will be kept, and you don't care which. Implementing equality across subclasses is really tricky if you need subclasses' objects to compare equal to parent objects. I suggest you avoid that, and only consider objects equal if their classes are exact matches (i.e. not just subtypes of one another). I highly recommend Rob Napier's talk on this: [this video] Here's a simple example: class Base: Equatable { let common: Int init() { common = 0 } func isEqua

Cites Cheok Yan Cheng · 2022-01 · Stack Overflow · on “How to make array of protocol at the same time conform to Equatable?”

Thanks to @Alexander and his pointed video resource - [this video] Here's is the good workaround, to overcome the current limitation of Swift's protocol. protocol Animal { func isEqual(to: Animal) -> Bool } func isEqual(lhs: [Animal], rhs: [Animal]) -> Bool { let count0 = lhs.count let count1 = rhs.count if count0 != count1 { return false } for i in 0..<count0 { if !(lhs[i].isEqual(to: rhs[i])) { return false } } return true } // struct. By conforming Equatable, struct is getting an auto // implementation of "static func == (lhs: Dog, rhs: Dog) -> Bool" struct Dog: Animal, Equatable { func isEqual(to other: Animal) -> Bool { guard let other = other as? Dog else { return false } return self == oth