> On Dec 10, 2015, at 10:13 AM, Matthew Johnson <matt...@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

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to