> On Apr 6, 2016, at 1:35 PM, Douglas Gregor <dgre...@apple.com > <mailto:dgre...@apple.com>> wrote: > > Fortunately, Swift tells you when you get it wrong.
It doesn't, though. That's the thing. 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 business 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. 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. I'm suggesting is we can all fire the QA engineer with a compiler feature. > 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”. What if we solve the problem at "framework-compile-time" rather than at "import-time"? 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. 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. The important thing is that it's zero-effort for consumers of the framework, and I get to fire my QA engineer.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
