[swift-dev] Initialization of default values

[Douglas Gregor]

> On Dec 10, 2015, at 10:13 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> Thanks Joe.  It sounds like in both current state and future state the compiler synthesizes additional arguments to the initializers for the type.  Is that correct?
> 
> Doug and Jordan, if you’re able to offer any additional insights that would be much appreciated as well.  I want to make sure my proposal aligns well with how you’re handling this.
> 
> This is some code showing my understand of how you describe current and future state.  Can you confirm if this is correct?
> 
> struct S {
>    let d: Double
>    let s: String = "default"
> 
>    // actual compiler generated signature is init(d: Double, s: String)
>    init(d: Double) {
>        // compiler generated initialization of s
>        // self.s = s
>        self.d = d
>    }
>    // current state compiler generated default value function
>    static func sDefault() -> String { return "default" }
> }
> 
> // current state: actual compiler generated call is S(d: 1, s: S.sDefault())
> // future state: actual compiler generated call is S(d: 1, s: "default")
> let s = S(d: 1)


Right now, we’re doing what Joe describes for default arguments of parameters only. So if you had written:

	struct S {
	  let d: Double
	  let s: String

	  init(d: Double, s: String = “default”) { … }
	}

	let s = S(d: 1)

the compiler would generate

>   // current state compiler generated default value function
>    static func sDefault() -> String { return "default" }

and call

	S(d: 1, s: sDefault())

The future state isn’t actually settled. We’re not thrilled with the idea of having to serialize expressions into Swift modules, which is what we would need to do to have the compiler turn the caller into

	S(d: 1, s: “default”)

The alternative that (IIRC) we’re currently favoring is to mark the SIL functions created as the default argument generators as “transparent”, so the SIL itself gets serialized into the Swift module and inlined into the call site (always). This is actually a smaller change to achieve the same effect, and avoids a lot of otherwise-unnecessary work to define the serialization of statements and expressions into Swift modules.

	- Doug