[swift-evolution] Python Interop with Swift 4+

[Chris Lattner]

> On Nov 20, 2017, at 12:50 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On 20 Nov 2017, at 21:10, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> 
>>>> On Nov 20, 2017, at 1:39 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> It is straight-forward (and fits very very naturally into the Swift call model) to support the second one as an atomic thing, which is I think what you’re getting at. 
>>> 
>>> What if you write ‘let fn = obj.method’?
>> 
>> That’s related to the DynamicMemberLookup proposal.  I’m not familiar with Ruby, but it sounds like the implementation would end up calling rb_iv_get/set to manipulate instance variables.  Is that your question or are you asking something else?
> 
> I don’t think that’s what he is asking. If `method` is indeed a method, then `obj.method` in Ruby would return the method as a `Proc` (If I’m not mistaken), ready to be called, very similarly to how it works in Swift:
> 
> class Foo {
>     func bar(_ a: String) {
>         print(a)
>     }
> }
> 
> let foo = Foo()
> let b = foo.bar
> b()

I’m not going to speculate what Slava meant (please speak up!), but given David Waite’s recent email, it isn’t clear that we’d want to provide this.  It seems reasonable for a Ruby interop layer to implement the DynamicCallable (in method only form?) but not DynamicMemberLookup.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171120/b092cf49/attachment.html>