<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 26, 2017, at 2:12 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks Michael for the manifesto. It definitely made quite a few things clearer for me.<div class=""><br class=""></div><div class="">Concerning the topic of when ABI stability should happen, I still have a strong feelings that Swift 4 might not be the best time for it. Concerning Data Layout, Type Metadata, Mangling, the Calling Convention and the Runtime, I don’t know enough about them to comment. I’m really centring my discussion on the Standard Library.</div><div class=""><br class=""></div><div class="">If we look back at the evolution of the Standard Library for Swift 3, they were many changes. And I’m personally very happy with the thoughtful design that went into those. But they are still a few gotchas, which is to be expected when so many changes are made at once. But we only discover them once the thousands of Swift developers start using those APIs.</div><div class=""><br class=""></div><div class="">I just worry that all the big changes that will come for Swift 4 won’t have time to mature. Furthermore, it seems like several extra compiler features which won’t happen in Swift 4 are really necessary to simplify the Standard Library surface area. I’m specifically thinking of type constraints on Existentials which would allow us to get rid of all the Any* structs and replace them with typedefs. But I’m sure there are more examples like those which are just waiting for the generics to become powerful enough to express APIs more elegantly.</div><div class=""><br class=""></div><div class="">Perhaps someone from the Standard Library team can chime in to give us their opinion on this topic.</div></div></div></blockquote><div><br class=""></div><div>I definitely share the concern about locking down ABI before:</div><div><br class=""></div><div>1) The language has the features required for the preferred standard library design.</div><div>2) The standard library team has had enough time and experience to be confident in the design of all aspects of the standard library which are frozen when ABI is frozen.</div><div><br class=""></div><div>One of the things I have appreciated most about Swift is the commitment to making the right decisions for the long term. It’s important that we don’t get locked into decisions in the standard library that don’t align with the most desirable long term design.</div><div><br class=""></div><div>Locking down ABI when all foreseeable desirable changes are additive is one thing. But doing so before we get there feels premature.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Thanks!</div><div class="">David.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 26 Jan 2017, at 00:09, Michael Ilseman via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">As described in e.g. <a href="https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable" class="">https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable</a>, it primarily enables OSes to ship with a copy of the standard library and runtime, rather than every app having to bundle their own copy. It’s also a crucial piece of supporting 3rd party frameworks. There are also more subtle benefits such as the de-coupling of developer tools that work with Swift binaries (e.g. debuggers and profilers). Some of the tasks towards stability are performance improvements we want to do anyways.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in place. Not saying the reasons for the urgency aren't valid, I just don't know what they are.<br class=""><br class="">Thanks!<br class=""><br class=""><blockquote type="cite" class="">On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jan 24, 2017, at 14:16, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class="">a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""><br class="">-- <br class="">Rick Mann<br class=""><a href="mailto:rmann@latencyzero.com" class="">rmann@latencyzero.com</a><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>