> 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

Reply via email to