> On Nov 12, 2017, at 3:33 AM, Tino Heth via swift-evolution
> <[email protected]> wrote:
>
>
>
>> Am 11.11.2017 um 19:03 schrieb Chris Lattner <[email protected]
>> <mailto:[email protected]>>:
>>
>>> Swift is quite flexible on what can act as a closure — would it be allowed
>>> to use a dynamic callable in that context?
>>> I guess forwarding of
>>>
>>> let closure: ([(String, Int)]) -> Int = DynamicCallableType()
>>>
>>> to the dynamicCall method of DynamicCallableType isn’t that hard, but
>>> wouldn’t it be odd if the value of closure changes when you leave out its
>>> type?
>>
>> I’m not sure I understand what you’re getting at. Can you show how this
>> would work with the example in the motivation section?
>
> I’m just asking if this should work ;-) — I didn’t see anything regarding it
> in the proposal.
> But to take something from the document:
>
> // file = open(filename)
> let file = Python.open.call(filename)
> let openFile: (String) -> FileHandle? = Python.open // is this be possible,
> or an error?
This would be an error. It is perfectly fine to do something like this:
func foo(a : PyRef) -> PyRef {
let b = a.foo // produces a PyRef
let c = b(“string”) // produces a PyRef
return c
}
The idea of this proposal is that in Python “everything is a python object”,
but that some of the objects are callable. This approach is modeling a python
object with some type (PyRef in the example above). It is totally possible to
produce sugar on top of that, or to go farther. For example, with no language
extensions, it is possible to do:
let closure: (String) -> Int = { arg in Int(pythonThing.call(args:
arg))! }
Or with this proposal, you could do something like:
let closure: (String) -> Int = { arg in Int(pythonThing(arg))! }
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
