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


swift-evolution mailing list

Reply via email to