On Wed, Apr 6, 2016 at 9:58 AM, Douglas Gregor via swift-evolution < [email protected]> wrote:
> > On Apr 5, 2016, at 4:04 PM, Drew Crawford <[email protected]> wrote: > > > On Apr 5, 2016, at 12:06 PM, Douglas Gregor <[email protected]> wrote: > > I would not want this to be implicit behavior: it should be recorded in > the source with, e.g., > > @availability(iOS: 9.3) import YourCustomFramework > > so that it is clear that the imported declarations are only available on > iOS 9.3 or newer. > > - Doug > > > Would you promote using this syntax for the Apple frameworks as well? > > > > A major goal for me is syntax consistency between Apple's and third-party > frameworks. That way the knowledge of how to use one transfers to the > other, and we ensure people with fresh ideas about how to build frameworks > are not burdened with educating application developers about "novel" import > syntax. > > > Apple frameworks tend to have ail their various classes and other APIs > annotated with availability attributes, so I wouldn’t expect to need this > import syntax for any of those. 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”. If your goal is consistency between > Apple frameworks and other frameworks, I don’t think this is the way to go. > > > Does this mean that the recommended best practice for framework authors is to set the deployment target low and then add an availability attribute for every public symbol?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
