I was watching a video on Julia about Multiple Dispatch and was curious if I could write something similar in Swift. I see that Swift relies on the compiler where Julia seems to determine a type at run time, but I also discovered something I don't understand about Swift.
Why would the below function encounters
work when the 2 parameters are of the same type of Pet but not when one is a Cat and the other is a Dog?
For example the two functions below work
encounters(Arturo, Gabby) // both Cat
encounters(Cc, Bb) // both Dog
but these give a compiler error
Conflicting arguments to generic parameter 'T' ('Cat' vs. 'Dog')
encounters(Arturo, Bb) // Cat and Dog
encounters(Bb, Arturo) // Dog and Cat
protocol Pet: Equatable {
var name: String { get }
}
struct Cat: Pet {
let name: String
}
struct Dog: Pet {
let name: String
}
let Arturo = Cat(name: "Arturo")
let Gabby = Cat(name: "Gabby")
let Bb = Dog(name: "Bb")
let Cc = Dog(name: "Cc")
func encounters<T: Pet>(_ a: T, _ b: T) {
var verb: String
switch (a, b) {
case is (Cat, Dog):
verb = meet(a as! Cat, b as! Dog)
case is (Dog, Dog):
verb = meet(a as! Dog, b as! Dog)
case is (Cat, Cat):
verb = meet(a as! Cat, b as! Cat)
case is (Dog, Cat):
verb = meet(a as! Dog, b as! Cat)
default:
fatalError()
}
print("\(a.name) meets \(b.name) and \(verb)")
}
func meet(_ a: Cat, _ b: Cat) -> String {
return "Slinks"
}
func meet(_ a: Cat, _ b: Dog) -> String {
return "Hisses"
}
func meet(_ a: Dog, _ b: Dog) -> String {
return "Howles"
}
func meet(_ a: Dog, _ b: Cat) -> String {
return "Barks"
}
I would not take this approach, but the reason it doesn't work is because you attached Equatable to Pet. You probably meant something like "Pets should be comparable to other Pets," but that's not what that means. It means that types that conform to Pet must themselves be Equatable. If you remove Equatable, this works as written without the generic as Claus notes:
So much
as!
makes Swift devs nervous and is unnecessary. Theas!
isn't wrong, but it opens the door for easy mistakes that the compiler can't catch. This style lets the compiler help you a little more. It still won't be able to catch missing cases.I definitely do not like the
fatalError
here. Both this code and the Julia I assume you've written would crash if some new Pet were created. That's not very good. But I assume it's not a major part of this question. In Swift, you'd put something in the default leg. In Julia, you'd add a more general multimethod formeet(a::Pet, b::Pet)
.If there really are only the two possible Pets, then you really should be thinking about enums instead of dynamic dispatch, but again I assume that's not the question.
Like I said, I don't really like this approach. I think it's very verbose, and adds a lot of places for mistakes. If you want this kind of dynamic type lookup, I'd do dynamic type lookup in data.
Even if you need functions, you can expand this to storing functions as data (which is an incredibly powerful way of implementing dynamic dispatch).
Instead of just a verb, add an action function to Meeting:
Now it's starting to look more like your multi-methods, putting all the specialized logic in one place:
And
encounters
calls it:It's not completely as powerful as multimethods, but it's easier to reason about the type safety at compile-time.