[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions
Jordan Rose
jordan_rose at apple.com
Tue Jan 5 18:09:13 CST 2016
> On Jan 4, 2016, at 20:59, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>
>>
>> On Jan 4, 2016, at 8:54 PM, Kevin Lundberg <kevin at klundberg.com <mailto:kevin at klundberg.com>> wrote:
>>
>> I like this idea, but I would imagine that for an extension with many functions in it, requiring @nonobjc on each one would get tedious very fast. Could it be required (or at least allowed in addition to per-method annotations) at the extension level?:
>>
>> @objc protocol P {}
>>
>> @nonobjc extension P {
>> func foo() { }
>> func bar() { }
>> func baz() { }
>> func blah() { }
>> // etc...
>> }
>>
>> I don’t know if this would have specific implementation ramifications over only doing this on each method, if extensions cannot already be modified with attributes. I can’t think of a case where I’ve seen annotations added to protocol extensions, or any other extensions for that matter.
>
> We have some declaration modifiers (e.g., access-control modifiers) and attributes (e.g., availability) that distribute in this manner from the extension to its members. My only hesitation here is that @objc itself doesn’t distribute in this way, and I’d rather they not be inconsistent.
I'd be much happier with this if we could do "@nonobjc extension", and I have no problems with "@objc extension" (even if it's rare). I suppose that would be a separate proposal.
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/52f95b87/attachment.html>
More information about the swift-evolution
mailing list