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 > On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution > <swift-evolution@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@swift.org <mailto: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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution