how does c code (and Python code, etc, other than ObjC) call Swift functions, methods, etc?
C. Keith Ray https://leanpub.com/wepntk <- buy my book? http://agilesolutionspace.blogspot.com/ twitter: @ckeithray http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf > On Nov 11, 2017, at 6:29 AM, Joe Groff via swift-evolution > <[email protected]> wrote: > > > >> On Nov 10, 2017, at 4:20 PM, Joe Groff <[email protected]> wrote: >> >> >> >>>> On Nov 10, 2017, at 4:12 PM, Charles Srstka <[email protected]> >>>> wrote: >>>> >>>> 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]> >>>>>> wrote: >>>>>> >>>>>> On Nov 10, 2017, at 5:36 PM, Joe Groff <[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. >> >> 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 > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
