<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 30. Nov 2017, at 09:24, Douglas Gregor 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; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 26, 2017, at 10:04 PM, 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=""><div class="">I’d like to formally propose the inclusion of user-defined dynamic member lookup types.<br class=""><br class="">Here is my latest draft of the proposal:<br class=""><a href="https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438" class="">https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438</a><br class=""><a href="https://github.com/apple/swift-evolution/pull/768" class="">https://github.com/apple/swift-evolution/pull/768</a><br class=""><br class="">An implementation of this design is available here:<br class="">https://github.com/apple/swift/pull/13076<br class=""><br class="">The implementation is straight-forward and (IMO) non-invasive in the compiler.<br class=""></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">Even the gaping hole that is AnyObject dispatch still requires the existence of an @objc declaration and produces an optional lookup result, so the user must contend with the potential for dynamic failure. Whenever we discuss adding more dynamic features to Swift, there’s a strong focus on maintaining that strong static type system.</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div>...<br class=""><div><br class=""></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=""><b class="">How Should Python Interoperability Work?</b></div><div class="">Going back to the central motivator for this proposal, I think that providing something akin to the Clang Importer provides the best interoperability experience: it would turn Python declarations into *real* Swift declarations, so that we get the various tooling benefits of having a strong statically-typed language.</div></div></div></blockquote><br class=""></div><div><br class=""></div><div>AnyObject doesn’t really come up too often in real-world Swift (in my experience, at least) exactly because of the Clang importer and the fact that Objective-C has adopted lots of annotations to make that importing experience better.</div><div><br class=""></div><div>We can’t expect other languages to do that, but IMO we’ll still need some kind of importer/wrapper generator. When Swift was first opened to the public, people started porting their Objective-C code and asking themselves the philosophical question: “Is this Swift?” - i.e. are you using Swift’s features, or are you basically writing Objective-C code using a wrapper language?</div><div><br class=""></div><div>Personally, I feel this system is designed to let you write Python, using Swift as a wrapper language - except unlike with Objective-C, it doesn’t have any static information about what you can do or not. It can’t provide the “safe by default” guarantees are other core principles and set Swift apart from other languages. When we consider interoperability with other languages, it should be from the perspective of mapping their features to Swift’s philosophies. This proposal takes the reverse approach, and makes Swift like Python, so I’m against it.</div><div><br class=""></div><div>- Karl</div></body></html>