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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
