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

[Joe Groff]

> On Nov 10, 2017, at 4:20 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
> 
>>> On Nov 10, 2017, at 4:12 PM, Charles Srstka <cocoadev at charlessoft.com> wrote:
>>> 
>>> 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> wrote:
>>>>> 
>>>>> On Nov 10, 2017, at 5:36 PM, Joe Groff <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.
> 
> As I mentioned in my original reply, I personally think the "importer" approach would be superior, and that in a perfect world we'd have type providers to make writing something like the ObjC importer but for a different language or other dynamic data source something that doesn't require invasive compiler hackery. The importer puts all of this:
> 
>> - 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.
> 
> below the fold as far as the rest of the language is concerned. You could just as well written what the importer synths up in Swift directly:
> 
> func foo(bar: String) {
>  unsafeBitCast(objc_msgSend, to: @convention(c) (AnyObject, Selector, NSString) -> ().self)(self, "fooWithBar:", NSString(bar))
> }
> 
> and the rest of the language would be none the wiser.

Though, since you bring up objc_msgSend, the way it works in ObjC might be a better fit for Swift's name lookup model, since their keyword argument models are similar. If Swift had a 'method of last resort' like ObjC's, say as a strawman you could overload the '.' operator, then you could use it to provide an implementation for a method given a compound name in a similar way. So if you had:

struct Dynamic { func .(methodName: String) -> (Any...) -> Int }

let x = Dynamic()
x.foo(x: 0, y: 1)

Then, when we do name lookup into x for foo(x:y:) and that fails, we'd fall back to turning this into x.`func .`("foo(x:y:)")(0, 1). It would take a bit more work to turn this into something like a Python call, but would fit Swift's language model better.

-Joe