In the previous article, we saw how Swift allows overloading by just the return type. With these kind of overloads, explicitly stating the type tells Swift which function you want to call:
// r will be of type Range<Int> let r = 1...5 // if you want a ClosedInterval<Int>, you // have to be explicit: let integer_interval: ClosedInterval = 1...5
But that still doesn’t explain why you get a Range back by default if you don’t specify what kind of return type you want. To answer that, we need to look at function arguments. We’ll start with just single-argument functions.
Unlike with return values, functions with the same name that take different types for their arguments don’t always need explicit disambiguation. Swift will try its best to pick one for you based on various best-match criteria.
As a rule of thumb, Swift likes to pick the most “specific” function possible based on the arguments passed. Swift’s fave thing, the thing that beats out all other single arguments, is a function that takes the exact type you’re passing.
If it can’t find a function that takes that exact type, the next preferred option is an inherited class or protocol. Child classes or protocols are preferred over parents.
To see this in action:
protocol P { }
protocol Q: P { }
struct S: Q { }
// this is the function that will be picked
// if called with type S
func f(s: S) { print("S") }
// if that weren't defined, this would be the next
// choice for a call passing in an S, since Q is
// more specialized than P:
func f(p: Q) { print("Q") }
// and then finally this
func f(p: P) { print("P") }
f(S()) // prints S
class C: P { }
class D: C { }
class E: D { }
// this is the function that will be picked
func f(d: D) { print("D") }
// if that weren't defined, this would be the next choice
func f(c: C) { print("C") }
// if neither were defined, the version above for the
// protocol P would be called
f(E()) // prints D
This prioritized overloading allows you to write more specialized functions for specific types. For example, suppose you want an overloaded version of contains for ClosedInterval that used the fact that you can do the check in constant rather than linear time using comparators.
Well, that sounds like a familiar concept – it’s polymorphism. But don’t get too carried away. It’s important to understand that:
Overloaded functions are chosen at compile time
In all the cases above, which function is called is determined statically not dynamically, at compile-time not run-time. This means it’s determined by the type of the variable not what the variable points to:
class C { }
class D: C { }
// function that takes the base class
func f(c: C) { print("C") }
// function that takes the child class
func f(d: D) { print("D") }
// the object x references is of type D,
// but x is of type C
let x: C = D()
// which function to call is determined by the
// type of x, and not what it points to
f(x) // Prints "C" _not_ "D"
// the same goes for protocols...
protocol P { }
struct S: P { }
func f(s: S) { print("S") }
func f(p: P) { print("P") }
let p: P = S()
// despite p pointing to an object of type S,
// the version that takes a P will be called:
f(p) // Prints "P" _not_ "S"
If instead you need run-time polymorphism – that is, you want the function to be picked based on what a variable points to and not what the type of the variable is – you should be using methods not functions:
class C {
func f() { print("C") }
}
class D: C {
override func f() { print("D") }
}
// function that takes the child class
// the object x references is of type D,
// but x is of type C:
let x: C = D()
// which method to call is determined by
// what x points to, and not what type it is
x.f() // Prints "D" _not_ "C"
The two approaches aren’t mutually exclusive, mind you. You could for example overload a function to take a particular protocol, checking for protocol conformance statically, but then invoke a method on that protocol to get dynamic behaviour.
The downside to that approach is that:
Functions that take Protocols can be ambiguous
With protocols, it’s possible to use multiple inheritance to generate ambiguous situations.
protocol P { }
protocol Q { }
struct S: P, Q { }
let s = S()
func f(p: P) { print("P") }
func f(p: Q) { print("Q") }
// error: argument could be either a P or a Q
f(s)
// so you need to disambiguate, either:
f(s as P) // prints P
// or:
let q: Q = S()
f(q) // prints Q
// the same happens with classes vs protocols:
class C { }
class D: C, P { }
func f(c: C) { print("C") }
// error: argument could be either a C or a P
f(D())
// you must specify, either:
f(D() as P)
// or:
f(D() as C)
Defaulting to ClosedInterval for Integers
So, knowing now that a function that takes a struct will be chosen ahead of a function that takes a protocol, we should be able to write a version of the ... operator that takes a struct (Int), that will beat the current versions that take protocols (Comparable to create a ClosedInterval, and ForwardIndex to create a Range):
func ...(start: Int, end: Int) -> ClosedInterval<Int> {
return ClosedInterval(start, end)
}
// x is now of type ClosedInterval
let x = 1...5
This is not very appealing though. If you pass in other integer types, you still get a Range:
let i: Int32 = 1, j: Int32 = 5 // r will be of type Range still: let r = i...j
It would be much better to write a generic version that took an IntegerType.
And it still doesn’t explain why ranges are preferred to closed intervals. Comparable and ForwardIndex don’t inherit from each other. Why isn’t it ambiguous, as in our protocol multiple inheritance example above?
Well, because I was lying when I said the current implementations of ... took a protocol. They actually take generic arguments constrained by protocols. The next article will look at how generic versions of functions fit into the matching criteria.
Airspeed Velocity 