[swift-evolution] [Review] SE-0160: Limiting @objc inference

Jordan Rose jordan_rose at apple.com
Thu Mar 23 12:06:42 CDT 2017


> On Mar 23, 2017, at 01:46, Slava Pestov <spestov at apple.com> wrote:
> 
> 
>> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md]
>> 
>> I'm definitely in favor of this. Apart from the various motivations discussed in the proposal, this also allows some changes that could improve incremental builds: the generated header ("MyApp-Swift.h") wouldn't need to be regenerated nearly as often with fewer methods exposed to Objective-C. (There's some nuance here that I don't need to go into right now, and there are alternate solutions to that problem, but it's nice that the common case will just put fewer declarations into the header and therefore it would change less often.)
>> 
>> The migration aspect is a little scary. #selector's Objective-C equivalent is @selector, which is easy to search for, but #keyPath maps to plain old strings.
> 
> Are these strings usually literal strings that are passed in to some set of mostly-known selector names, or do people pass them around or even construct them dynamically?

Yeah, that's a saving factor. If someone made a list of all the KVC/KVO/bindings APIs and looked for uses in their project, they'd probably get most of them (with the minor complication of the argument usually being a key path and not just a single key).

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170323/708d680f/attachment.html>


More information about the swift-evolution mailing list