[swift-evolution] [pitch] make @nonobjc the default

[Jay Abbott]

Ok, good to know that's just a bug. But I still think that implicit @objc
should be removed. For bridged classes with obj-c-specific interfaces (for
example a method that takes a selector), it would be better if the
Swift-side interface was forced to make a Swifty interface that hides it.
This way, the people maintaining an interface have to either a) write a
wrapper with a Swifty interface; or b) explicitly cop out and use @objc and
inform their users that they may also have to do the same in some
situations; or c) persuade their employers to let them port the whole thing
to pure Swift, which sounds like a lot of fun and is probably what they
really want to do :D.

I'm not really sure how this works though, at what level this is applied?
Maybe it's more to do with the default build settings in Xcode than Swift
itself? I just would rather see Swift stand alone by default.



On Wed, 19 Oct 2016 at 03:51 Douglas Gregor <dgregor at apple.com> wrote:

>
>
> Sent from my iPhone
>
> > On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Currently, if you extend a class that comes from obj-c, Swift assumes
> you want to make those methods available to call from obj-c code. If you
> add operators, you must declare them as @nonobjc otherwise the bridging
> header which is generated declares obj-c methods with the operator
> character as the method name, which isn't valid in obj-c and causes compile
> errors.
>
> The operators bit is an outright bug, which I believe has already been
> fixed in master.
>
> > I'm just wondering how others feel about this - my feeling is that a
> Swift developer should not have to know anything about obj-c when doing
> Swifty things to a bridged class from a framework (such as extending it).
> As far as they are concerned the framework class should compile the same as
> if it were fully implemented in Swift.
>
> Modulo bugs like the above, I think we already have this property? Swift
> declarations are exposed to Objective-C if they can be. One doesn't
> generally have to think about it unless you're trying to use those
> declarations from Objective-C.
>
> > Thoughts?
>
> I actually thought you were going further with this, eliminating the
> inferred @objc except in cases where it's needed to work with an existing
> framework. That's something I'd love to see someone working on.
>
>   - Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161019/def36837/attachment.html>