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

[Chris Lattner]

> On Nov 30, 2017, at 6:15 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>> 
>> I think better interoperability with Python (and other OO languages in widespread use) is a good goal, and I agree that the implementation of the feature described is straight-forward and not terribly invasive in the compiler.
>> 
>> However, I do not think this proposal is going in the right direction for Swift. I have objections on several different grounds.
> 
> +1 to everything Doug says here.  He articulates the concerns I tried to voice in an earlier thread more clearly and more thoroughly.  

Doug’s email was pretty confusing, so I’ll try to clear up some of the misconceptions here.  I also updated the proposal with a new section at the end, please check it out.

> This design introduces a significant hole in the type system which is contrary to the spirit of Swift.

There is no “hole” in the type system.  The proposal is fully type safe. 

Further, the addition is absolutely in the spirit of Swift, because it is directly analogous to an existing feature: AnyObject lookup.  The difference between it and AnyObject lookup is that AnyObject lookup is:

a) specific to Objective-C interop
b) type unsafe
c) massively invasive on the rest of the compiler.

We’ve made many attempts to narrow the scope of AnyObject lookup, but it is difficult to do so given backwards compatibility constraints and the limited nature of Objective-C metadata.

>  It doesn’t just make dynamic language interop easy, it also changes the semantics of any type which conforms to DynamicMemberLookupProtocol.  That is not something that is locally visible when looking at a piece of code.  Worse, it does so in a way that trivial mistakes such as a typo can turn into runtime errors.  Worst of all, as Doug points out it is possible to use retroactive conformance to change the semantics of vast quantities of widely used types in one fell swoop.

This is a feature, like many others, which can be misused.  This has not been the metric we have used to judge what should go into Swift.  I can elaborate if my response to Doug wasn’t clear.

> One additional concern that I don’t believe has been mentioned is that of evolution.  When a library is imported from a dynamic language and the library makes breaking changes Swift code written using this feature will break without notice until a runtime error occurs.  Is that acceptable?  That may be what users of dynamic languages are accustomed to but can we do better in Swift?  If we can make the process of upgrading dependencies less a less harrowing experience perhaps that could be a major selling point in moving them to Swift.  But we won’t accomplish that with this design.

How would you this to work with *any* interoperability approach?  Dynamic languages are in fact dynamic, and need the ability to do dynamic lookups somehow.  Those dynamic lookups will all have the problem you observe.

> Interop with dynamic languages is a worthy goal, but we should do it in a way that has no potential impact on code that does not need the feature.  A semantic variant of “don’t pay for what you don’t use” should apply here.  If we add this feature everyone will pay for it every time they read unfamiliar Swift code.  They will have to contend with the potential for conformances to this protocol, even on standard library types.  That feels like a pretty high cost to me, especially for programmers who aren’t using the dynamic language interop features themselves.

You seem to fear that people will pervasively adopt this and use it for weird things.  While that is possible, that would be simply one way to misuse Swift.  What makes it more likely for someone to do this than to use unsafe features incorrectly, providing an apparently type safe API that actually isn’t?

> Further, a consistent theme has been the desire to avoid things like compiler flags that could fragment the community.  I fear this feature has the potential to do that, especially if it is really successful at attracting people from the dynamic language community.  

I really fail to see how this concern relates here.  This has nothing to do with compiler flags.  This has the potential to expand the community, not fragment it.

-Chris