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

[Magnus Ahltorp]

> 6 Dec. 2017 16:51 Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Ok, I have changed my mind about the need for a marker, and will accept the proposal as-is.  I realized that these dynamic member lookup types can just be made inner types, and so I can easily create the .dynamic behavior in my own code if I want under the current proposal.  I also realized that requiring a marker would screw up the proxy use-case of this.
> 
> I do still have a couple of questions I am confused on:
> 
> 1) How do operators work with this?  I saw you give an example of a+b for python types, but I don’t see where either proposal bridges operators. (I could easily have missed it though)

Operators can be bridged using the existing Swift mechanisms, in this case operator overloading, so the proposal does not need to address operators.

> 2) What if I need two separate python libraries?  The code says ‘let np = Python.import(“numpy”)’.  Are we supposed to make a separate variable for each import?
> 
> 3) How will inter-op between Swift types and Python types work?  It looks like you are just passing strings and integer constants to python functions. Do they get converted automatically, or do we have to explicitly convert them?  I am guessing this is using expressibleBy___ to work?

All of these will be up to the Python bridge implementation or implementations. This proposal is not a proposal of how to bridge Python and Swift, it is only enabling (not requiring) a decent syntax for these kinds of bridges.

/Magnus