[swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

[Charles Srstka]

> On Nov 10, 2017, at 5:51 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
> 
>> On Nov 10, 2017, at 3:45 PM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> 
>>> On Nov 10, 2017, at 5:36 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> 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

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