<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=""><div><div class=""><br class=""></div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2016, at 1:35 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Fortunately, Swift tells you when you get it wrong.</span></div></blockquote></div><br class=""><div class="">It doesn't, though. That's the thing.</div><div class=""><br class=""></div><div class="">Consider CloudKit, first available in iOS 8. Does that framework's implementation rely on new, novel APIs only available on iOS 8, and the Swift compiler threw availability errors to the implementor of CloudKit? Or, is the reason the reason it's "unavailable" in 7 because Apple decided as a point of <i class="">business</i> not to compile, test, and QA an iOS 7.3 that added CloudKit? Well I don't have the sourcecode so I don't know, maybe there is some incredibly novel API involved in talking to computers on the internet not available in iOS 7. But I suspect it's mostly a business decision, not technical.</div><div class=""><br class=""></div><div class="">So, if we assume that's the case (or, if I'm wrong, replace CK with a framework for which there is no technical reason why it's unavailable), then Apple paid some QA engineer to sprinkle @available on all the public APIs. Meanwhile, third-party developers in this situation are similarly making business decisions not to support iOS 7/8, and we also have to grab our QA engineer and comb through the API very carefully.</div><div class=""><br class=""></div><div class="">I'm suggesting is we can all fire the QA engineer with a compiler feature.</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">Really, this syntax is a shorthand for “treat the imported library as if the author had put this availability annotation on all of its public APIs”.</div></blockquote><div class=""><br class=""></div><div class="">What if we solve the problem at "framework-compile-time" rather than at "import-time"?</div><div class=""><br class=""></div><div class="">Suppose we have some driver flag that injects @availability onto every decl in the module. For decls with existing @availability it simply raises the floor to some minimum value. Now we distribute the module, and the availabilities have been set.</div><div class=""><br class=""></div><div class="">My intuition would be to use the existing "deployment target" flag to control this feature, since this is how framework authors actually do express their intent to support an OS. But if we need to introduce a novel concept of an "availability target", that's fine too.</div><div class=""><br class=""></div><div class="">The important thing is that it's zero-effort for consumers of the framework, and I get to fire my QA engineer.</div></div></div></div><br class=""></body></html>