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 <matt...@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 <dgre...@apple.com> wrote:
>>
>>
>>> 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
