> On Mar 23, 2017, at 01:46, Slava Pestov <spes...@apple.com> wrote: > > >> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution >> <swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution