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

[susan.doggie at gmail.com]

Hi all,

I have few problems with this proposal.

How we guarantee the arguments type are what we need?

If we passing the type to the dynamicCall that are not acceptable, what will happened?

Should we always write the dynamicCall as a throwing function to check the precondition?

Instead of introducing dynamic calls, I would like introducing mirror of instance methods.

> Joe Groff via swift-evolution <swift-evolution at swift.org> 於 2017年11月11日 上午8:20 寫道：
> 
> 
> 
>>> 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.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution