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

Chris Lattner clattner at nondot.org
Wed Dec 20 15:36:35 CST 2017

> 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.


More information about the swift-evolution mailing list