[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Karl Wagner]

> On 30. Nov 2017, at 09:24, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I’d like to formally propose the inclusion of user-defined dynamic member lookup types.
>> 
>> Here is my latest draft of the proposal:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438>
>> https://github.com/apple/swift-evolution/pull/768
>> 
>> An implementation of this design is available here:
>> https://github.com/apple/swift/pull/13076
>> 
>> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> 
> 
> 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.
> 

...


> How Should Python Interoperability Work?
> 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.


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.

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?

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.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171130/76779da8/attachment.html>