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

[Chris Lattner]

> On Dec 20, 2017, at 1:36 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Dec 19, 2017, at 11:26 PM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>>> Beyond that, they are small extensions with low complexity, scale to supporting many different dynamic languages over time,  require a level of engineering effort that is plausible to be built, and do not require some sort of "executive buy in” from the Python community.
>> 
>> Here’s an alternative proposal that provides a better development experience: write a wrapper generator, in Python, that maps a Python module’s interfaces to Swift, and provide small tie-ins to the compiler to make it fit well. Take the example from the DynamicMemberLookup proposal:
> 
> Doug and I and the rest of the core team discussed this today, and agreed that the foreign class idea proposed isn’t necessary - the majority of the value is being provided by the generated wrapper code, and that wrapper code composes on top of the existing Python prototype with no additional language features.  Given that, we’re not pursuing the ‘foreign class’ idea.
> 
> That said, if wrappers are sufficient to solve the problem, that could eliminate the need for the other two proposals entirely.  I’m going to explore this a bit to understand the limitations and advantages of this approach and will get back to this list (in a new thread) in a couple weeks.

One other thing: I believe that there was agreement in the meeting that generating a good code completion experience can work with any of these proposals, through reasonable extensions to SourceKit.  Doing a good job of code completion for python APIs involves doing some heuristic control flow analysis stuff that doesn’t already exist in the existing Swift toolchain anyway.  I believe we’re now focused on whether wrappers can be “good enough” to solve the problem without other language extensions.

-Chris