> On Apr 6, 2016, at 11:04 AM, Jonathan Tang <[email protected]> wrote:
>
>
>
> On Wed, Apr 6, 2016 at 9:58 AM, Douglas Gregor via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On Apr 5, 2016, at 4:04 PM, Drew Crawford <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Apr 5, 2016, at 12:06 PM, Douglas Gregor <[email protected]
>>> <mailto:[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?
Every public symbol that needs it, sure. Fortunately, Swift tells you when you
get it wrong.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
