> On Feb 16, 2017, at 10:17 PM, Chris Lattner <clatt...@nondot.org> wrote:
>
> On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Deferring ABI Stability from Swift 4
>>
>> Given the importance of getting the core ABI and the related fundamentals
>> correct, we are going to defer the declaration of ABI stability out of Swift
>> 4 while still focusing the majority of effort to get to the point where the
>> ABI can be declared stable.
>>
> Given where we are in the yearly schedule, I think that this is a pragmatic
> decision. ABI stability is far more important to Apple than it is to most
> developers, so I’m happy to see that you’re prioritizing the needs of the
> community (improved compile time, compiler stability, etc), particularly
> given the importance of doing the right thing for the long term success of
> Swift.
>
> Beyond that, I agree that it is prudent to continue work on the many ABI
> stability tasks despite it not being a goal for Swift 4. Given the
> significance of declaring ABI stability, it would be great to get these tasks
> really nailed down early in the Swift 5 schedule so you have time to bake it
> out.
Absolutely — giving time for these changes to bake to make sure we did not miss
anything is essential part of keeping the focus in Swift 4 on core ABI
stability tasks (and other language fundamentals that impact ABI and source
stability). That thinking went into the scoping of stage 2.
>
> Do you have any idea what the typical download size impact of the Swift 4
> libraries will be on the ARM64 slice of a typical iOS app? I know that many
> of the ABI-related optimizations also contribute to a significant code size
> improvement, but don’t know how folks expect that to net out. Do you think
> that it is plausible to get the overlays coalesced with the stdlib into a
> single dylib, improving app launch times?
This is an interesting idea, but off-topic for swift-evolution. A better place
to discuss this is swift-dev.
That said, there are tradeoffs here: creating a single dylib slightly
complicates the long-term goal of sinking the overlay APIs back into the OS,
and the number of overlays is not guaranteed to remain fixed so the tradeoffs
of creating a single dylib versus multiple are nuanced. The focus has been on
the ABI-related optimizations, such as reducing the size of mangled symbols,
which are tasks that absolutely need to be done before ABI stability.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
