> On Oct 19, 2016, at 10:37 AM, Joe Groff <[email protected]> wrote:
>
>>
>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Oct 19, 2016, at 4:53 AM, Jay Abbott <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Ok, good to know that's just a bug. But I still think that implicit @objc
>>> should be removed.
>>
>> Oh, I agree that implicit @objc should be removed. I suspect it’s
>> responsible for a nontrivial amount of code bloat and unnecessary
>> Objective-C selector collisions.
>>
>>> 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 don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit
>> the amount of glue code one needs to write.
>>
>>> 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.
>>
>> I think it’s a Swift language change: we should only infer ‘@objc’ when the
>> API
>>
>> * Overrides of an @objc API,
>> * Satisfies a requirement of an @objc protocol, or
>> * Uses a Swift feature that requires the Objective-C runtime (e.g.,
>> @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)
>
> It might also be nice if referring to a method with #selector automatically
> tried to make it @objc.
It might, although I don’t love the impact on the implementation: we either end
up creating one-off categories associated with the references to non-@objc
methods or our type checker has to process function bodies to answer the
question “is this method exposed to Objective-C”?
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
