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?
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_r...@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 <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
