<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div class="">Furthermore, the old code needs to continue working <i class="">without source changes,</i> because updating to a new SDK must not break existing code. (It can introduce new warnings, but even that is something that should be considered carefully.)</div><div class=""><br class=""></div><div class="">So: this proposal is designed to handle the use cases both for Swift library authors to come and for C APIs today, and in particular Apple's Objective-C SDKs and how they've evolved historically.</div></div></blockquote><br><div>I will let your very comprehensive rationale brew a little bit more in my mind and reread it, but I still think this is a bit leaning too much over to library authors than library consumers (not unlike the closed by default discussion we all had a while ago).</div><div><br></div><div>I remain very unconvinced by the “updating library/SDK” must be source compatible. Especially if it is major version change and a deprecated method has been removed, methods have changed signature, etc... Backward compatible runtime with code compiled against the previous SDK yes, source compatible no.</div><div><br></div><div>I feel like this change will make the life easier for library authors, but risks making it easier and easier to make mistakes in apps using the libraries: exhaustive switching over enums is a good important feature that risks going away (the default matters) for not a huge effective benefit to app developers.</div></body></html>