[swift-dev] Initialization of default values

[Douglas Gregor]

> On Dec 11, 2015, at 7:34 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> Thanks Jordan.  I was guessing a synthesis like this was happening but didn't want to assume without asking.
> 
> Is the initialization of members with initial values synthesized at the beginning of the initializer body before any user code?  If not, at what point in the initializer does this happen?

At the beginning. See SILGenFunction::emitMemberInitializers.

	- Doug

> 
> Also, thanks for filling me in on the terminology distinction.  I'll try to remember that!
> 
> Matthew
> 
> Sent from my iPad
> 
>> On Dec 11, 2015, at 8:26 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>> Members with initial values get their initialization synthesized into the body of the type's initializer. I think we do this during SILGen, i.e. when we go to emit a SIL body for the ConstructorDecl AST node.
>> 
>> (We use the term "initial value" for "the thing on the right side of the equal sign for a variable or constant" and "default value" for "the thing on the right side of the equal side for a parameter".)
>> 
>> Jordan
>> 
>> 
>>> On Dec 11, 2015, at 16:28 , Matthew Johnson <matthew at anandabits.com> wrote:
>>> 
>>> Thanks Doug, that makes sense.  I was wondering if Joe's answer might have been referring to arguments with defaults.  
>>> 
>>> What are you doing for members with default values specific (and therefore not initialized by code in an initializer)?  Do you plan changes to this as well?
>>> 
>>> Matthew
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>>> On Dec 11, 2015, at 5:11 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>>> 
>>>> 
>>>>> 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
>>>> 
>>