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

[Jon Gilbert]

On Dec 1, 2017, at 02:44, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> So the use case here is, how do we make Swift a viable candidate for doing those things which today drive users to Python? The answer here is _not_: build a better Python. Nor does it require, out of the gate, even being as good as Python. The solution is to provide a _reasonably_ ergonomic to _interoperate with libraries available in Python_, with the benefit that those parts that you can write in native Swift will make the overall result safer and faster, etc.

I think we would be better served by a transpiler that translates Python (etc.) into Swift at compile time. 

Look what Google did with j2objc (https://github.com/google/j2objc). It translates Java right into Objective C. You can even put your Java code right in XCode and it auto-translates at build time. 

Clearly, this is no small feat, and j2objc is a technical marvel that took world-class engineers years to perfect. 

My point is, “Dynamic Member Lookup” is not the only solution, and it’s not the ideal solution if indeed it compromises the static guarantees of Swift.

Therefore, we should consider what other approaches might entail. The main players in Swift have lots of money and technical resources they could pour into a set of revolutionary transpilers. 

Surely we don’t want to allow Goole to be the only company to provide a library that translates other codebases directly to a primarily Apple language, do we?

That being said, I am still interested to hear Chris’s response to these concerns, and if they were already addressed on a previous message and I missed that, then please forgive me.

- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171201/0c3b7658/attachment.html>