[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor]

> On Jan 4, 2016, at 8:58 PM, John Joyce <uchuugaka at icloud.com> wrote:
> 
> Would it not be possible to do the relative analog of Objective-C nullability macro sandwiches in Swift?
> And then allowing exceptions within the file to be called out explicitly with @nonobjc or @objc ?
> @begin_assume_nonobjc
> @end_assume_nonobjc
> @begin_assume_objc
> @begin_assume_objc

Ick :)

If we need to annotate several things at once, doing it an extension granularity is good enough, because there’s essentially no cost to merging or breaking apart extensions as needed.

	- Doug

>> On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
>> 
>> 
>>> On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> We currently have a bit of a surprise when one extends an @objc protocol:
>>> 
>>> @objc protocol P { }
>>> 
>>> extension P {
>>>   func bar() { }
>>> }
>>> 
>>> class C : NSObject { }
>>> 
>>> let c = C()
>>> print(c.respondsToSelector("bar")) // prints "false"
>>> 
>>> because the members of the extension are not exposed to the Objective-C runtime. 
>>> 
>>> There is no direct way to implement Objective-C entry points for protocol extensions. One would effectively have to install a category on every Objective-C root class [*] with the default implementation or somehow intercept all of the operations that might involve that selector. 
>>> 
>>> Alternately, and more simply, we could require @nonobjc on members of @objc protocol extensions, as an explicit indicator that the member is not exposed to Objective-C. It’ll eliminate surprise and, should we ever find both the mechanism and motivation to make default implementations of @objc protocol extension members work, we could easily remove the restriction at that time.
>>> 
>>> 	- Doug
>>> 
>>> [*] Assuming you can enumerate them, although NSObject and the hidden SwiftObject cover the 99%. Even so, that it’s correct either, because the root class itself might default such a method, and the category version would conflict with it, so...
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160104/717f1a4b/attachment.html>