The current ABI for default arguments generate explicit functions for each default argument in a function. As a simple example, when you call something like this:
// In the defining module.
func foo(a: Int, b: Int = 42, c: Float = 3.14) {
...
}
// On the caller side.
foo(a: 192)
it compiles into the equivalent of:
// In the defining module.
func foo_impl(a: Int, b: Int, c: Float) {...}
func foo_b() -> Int { return 42 }
func foo_c() -> Float { return 3.14 }
// On the caller side.
let bval = foo_b()
let cval = foo_c()
foo_impl(a: 192, b: bval, c: cval)
This approach seems suboptimal for a bunch of reasons: 1) it bloats code size on the caller, and most functions have many callers but a single implementation. 2) it generates multiple symbols for the function, each of which need to be exported from a dylib and mangled, bloating object size and slowing dyld. 3) if default argument types are resilient in the caller but known in the callee this generates inefficient code. 4) The callee doesn't see these default values, which can affect optimizations within the callee. 5) These functions are tiny, and not great for the branch predictor, particularly when calling across dylibs (which involve a call through an indirect stub).
The code bloat in particular can be quite large, just look what simple calls to print turn into for example.
I know the goal here is to allow evolution of these default values, but we could achieve the same semantic result by changing the ABI to implicitly hoist these things to optionals and pass defaults as nil. For example, we could compile the above into code like this:
// In the defining module.
func foo_impl(a: Int, b bval: Int?, c val: Float?) {
let b = bval ?? 42
let c = cval ?? 3.14
...
}
// On the caller side.
foo_impl(a: 192, b: nil, c: nil)
Has anyone considered doing this?
-Chris