[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.


-------------- 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