> On 30. Nov 2017, at 09:24, Douglas Gregor via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
>> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
