> On Dec 20, 2017, at 1:36 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Dec 19, 2017, at 11:26 PM, Douglas Gregor <dgre...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
