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

[Andrew Bennett]

I'm on the fence here, I think it's a good solution if a project has
ongoing objc dependencies.

However I have a few issues/suggestions:

1) If a project is iteratively migrating from objc to swift, as I'm sure
many are (a large project I'm working on included), then it would make that
job much more tedious and increase the objc footprint in the swift code.

2) A linter could help me slowly remove unnecessary side-effects of this
proposal, but it's not ideal, and it does not solve the large amounts of
annotations needed to do so.

3) If this proposal went ahead would existing code be migrated to add the
annotation everywhere? (to retain equivalence)

4) Have you explored any alternatives?
 * instead of defaulting to @objc require an explicit @objc or @nonobjc,
otherwise have a compile-time warning; default to @nonobjc still (for
consistency).
 * @objc(inherit=false)

when put on the protocol it disables what you propose, inherit is true by
default.

 * compile time feedback:
    + An objc compile time warning/error suggesting you add @objc if
there's no matching selector, but there is a swift method.

This may only work in whole module optimisation, also the dynamic nature of
objc may prevent it from being deterministic.

    + A swift compile time warning/error suggesting you add @objc if
there's an objc protocol and an unannotated swift implementation.

If I remember correctly something like this may already exist.




On Tue, Jan 5, 2016 at 4:02 PM, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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> 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> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/ac25e523/attachment-0001.html>