[swift-evolution] deployment targets and frameworks

Jonathan Tang jonathan.d.tang at gmail.com
Wed Apr 6 13:04:01 CDT 2016


On Wed, Apr 6, 2016 at 9:58 AM, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Apr 5, 2016, at 4:04 PM, Drew Crawford <drew at sealedabstract.com> wrote:
>
>
> On Apr 5, 2016, at 12:06 PM, Douglas Gregor <dgregor at apple.com> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160406/f0172d20/attachment.html>


More information about the swift-evolution mailing list