[swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

[Chris Lattner]

> On Nov 12, 2017, at 3:33 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> Am 11.11.2017 um 19:03 schrieb Chris Lattner <sabre at nondot.org <mailto:sabre at nondot.org>>:
>> 
>>> 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


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