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
