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

[Karl Wagner]

> On 1. Dec 2017, at 07:05, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Doug,
> 
> Thank you for the detailed email.  I have been traveling today, so I haven’t had a chance to respond until now.  I haven’t read the down-thread emails, so I apologize if any of this was already discussed:
> 
>> 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.
> 
> Fantastic, I’m really pleased to hear that!  I only care about solving the problem, so if we can find a good technical solution to the problems than I’ll be happy.
> 
> A funny thing about swift-evolution is that it is populated with lots of people who already use Swift and want to see incremental improvements, but the people who *aren’t* using Swift yet (but should be) aren’t represented here.  As you know, I’m perhaps the biggest proponent of Swift spreading into new domains and earning the love of new users.


I don’t really appreciate that argument. You also need to consider: what improvements are we offering these people who don’t yet use Swift?

For Objective-C developers, the static typing and resulting performance and safety improvements made this a worthwhile switch. Plus, we could interoperate very well with existing Objective-C codebases and libraries (e.g. we can have generic subclasses of NSObject!), so we could actually use a lot of these nice features when writing our mac/iOS applications.

For Python developers, I gather the pitch would be similar: Swift has all kinds of nice features which will make your code safer and faster. We’re unlikely to achieve the same tight integration with Python (or any other language) that we have with Objective-C, though. We used to rely a lot on AnyObject, but since Objective-C made the importing experience so much better, you rarely (if ever) see it in practice. Objective-C can also be more dynamic than we show it as - you can have methods which are not declared anywhere, and which the object synthesises during its message-handling routines. We don’t support calling these non-existing methods on Objective-C objects, so why should we allow it for these objects?

My worry is that in eagerness to try and scoop up developers of other languages, that we diminish the Swift language to the point where it doesn’t really provide a benefit for them. Python developers will be writing the same unsafe, non-checked code using Swift that they do in Python; where’s the win?

- Karl