<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Nov 10, 2017, at 5:51 PM, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class="">Hi Chris,<br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hello all,</div><div class=""><br class=""></div><div class="">I have a couple of proposals cooking in a quest to make Swift interoperate with dynamically typed languages like Python better. Instead of baking in hard coded support for one language or the other, I’m preferring to add a few small but general purpose capabilities to Swift. This is the first, which allows a Swift type to become “callable”.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I’m generally in favor of adding new features if they simplify the language model or subsume existing special cases, either moving them into the standard library or simplifying their implementation. </div></div></div></div></blockquote><div><br class=""></div><div>Great!</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">However this proposal looks like a strictly additive feature, </div></div></div></div></blockquote><div><br class=""></div><div>It is. It is strictly sugar, as mentioned in the proposal.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">which introduces yet another kind of callable thing. We already have:</div><div class=""><br class=""></div><div class="">- Statically dispatched functions</div><div class="">- VTable-dispatched class methods</div><div class="">- Witness table dispatched protocol methods</div><div class="">- ObjC methods</div><div class="">- Dynamic method dispatch on AnyObject</div><div class="">- Enum case constructors</div><div class="">- Curried functions and various thunks, etc</div><div class=""><br class=""></div><div class="">I don’t see the new dynamic callable you are proposing replacing or generalizing any of the above, it will simply be a whole new code path.</div></div></div></div></blockquote><div><br class=""></div><div>These things are completely different in character. They are not sugar: they are invasive changes that spread through the rest of the compiler. They are also (generally) not part of the user exposed semantic model for swift, they are implementation mechanics. This proposal if far less invasive, and also quite different than these.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">This all comes at a great cost. If you look at the implementation of calls in lib/SILGen/SILGenApply.cpp you will see there is a great deal of complexity there to deal with all the different special cases. The type checker also has a lot of complexity related to method calls and member accesses.</div></div></div></div></blockquote><div><br class=""></div><div>I do not expect any SIL or IRGen changes associated with this proposal, just type checker changes. The type checker changes should be straight-forward, but you can evaluate that when there is a patch.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span style="color: rgb(36, 41, 46); font-family: -apple-system, system-ui, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; font-size: 16px; orphans: 2; widows: 2;" class="">Swift is well known for being exceptional at interworking with existing C and Objective-C APIs, but its support for calling APIs written in scripting langauges like Python, Perl, and Ruby is quite lacking. These languages provide an extremely dynamic programming model where almost everything is discovered at runtime.</span></div></div></blockquote><div class=""><br class=""></div><div class="">Most other statically compiled languages don’t attempt to solve this problem of interoperating with Python and Ruby either.</div></div></div></div></blockquote><div><br class=""></div><div>Our goal is for Swift to be awesome, not comparable to “other statically typed languages”.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""> I’m not sure this is a feature users expect or one that should be prioritized, given all the other work that remains in the implementation that will actually improve the day to day experience of developers.</div></div></div></div></blockquote><div><br class=""></div><div>swift-evolution isn’t about priorities. I’m not asking someone else to implement this, and you don’t tell me how I spend my engineering time :-) :-)</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, system-ui, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; font-variant-ligatures: normal; orphans: 2; widows: 2;" class="">We propose introducing this protocol to the standard library:</p><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, system-ui, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; font-variant-ligatures: normal; orphans: 2; widows: 2;"><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; margin-top: 0px; margin-bottom: 0px; word-wrap: normal; padding: 16px; overflow: auto; line-height: 1.45; background-color: rgb(246, 248, 250); border-radius: 3px; word-break: normal;" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">protocol</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(111, 66, 193);">DynamicCallable</span> {
<span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">associatedtype</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">DynamicCallableArgument</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">associatedtype</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">DynamicCallableResult</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(111, 66, 193);">dynamicCall</span>(<span class="pl-smi" style="box-sizing: border-box;"><span class="pl-en" style="box-sizing: border-box; color: rgb(111, 66, 193);">arguments</span></span>: [(<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">String</span>, DynamicCallableArgument)]) <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">throws</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">-></span> DynamicCallableResult
}</pre></div></div></div></blockquote><div class="">This is not really very general at all, because it assumes all arguments have the same type, along with all results. </div></div></div></div></blockquote><div><br class=""></div><div>Correct. This is important and common for interoperating with dynamic languages.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">Why would arguments and results have different types if they’re type erased anyway? </div></div></div></div></blockquote><div><br class=""></div><div>I’m open to requiring these to be the same type if there is a benefit to doing so. What benefit do you see?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">And why are string keyword names privileged in any way? What about varargs, inout parameters and other Swift-specific modifiers on calls?</div></div></div></div></blockquote><div><br class=""></div><div>Because dynamic languages support keywords, and this is all about reflecting APIs written in those languages into Swift. This API works fine for varargs. Dynamic languages do not support Swift specific keywords and (generally) do not support inout.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div></body></html>