> On Nov 10, 2017, at 5:51 PM, Joe Groff <[email protected]> wrote: > > > >> On Nov 10, 2017, at 3:45 PM, Charles Srstka <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Nov 10, 2017, at 5:36 PM, Joe Groff <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> How `MyObject.foo(_:bar:)` gets implemented is its own business, as far as >>> the compiler is concerned. The compile-time name resolution for the method >>> isn't impacted. >>> >>> -Joe >> >> The compile-time name resolution for the method doesn’t happen *at all.* > > You declared the method in your @interface, and the compiler saw that and > brought it in as what Swift considers to be a regular method, and your call > on the Swift side was resolved to it by Swift's usual lookup rules. To do > what Chris is suggesting requires changing the way calls get resolved in the > compiler before the call is even formed.
The only thing that makes this the “usual lookup rules” is that the Objective-C bridge has already been implemented. Consider scenario in which the Objective-C bridge does not exist, and someone is proposing it. As I see it, all these objections will apply to it just the same. For the following method: @objc dynamic func foo(bar: String) - It’s changing the compile-time name resolution! The Swift name is foo(bar:), but it’s changing that to fooWithBar:! - It’s changing the signature! The argument took a String, but now it’s passing an NSString! - It’s not resolving the method at compile-time! It’s passing the modified method name and the arg list to some objc_msgSend() function, which resolves it dynamically in a way that user code can intercept and interpret at runtime! I’m just not seeing the conceptual difference here. Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
