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

[Matthew Johnson]

Sent from my iPad

> On Nov 10, 2017, at 12:51 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Nov 10, 2017, at 10:41 AM, Chris Lattner <sabre at nondot.org> wrote:
>> 
>> On Nov 10, 2017, at 10:03 AM, Joe Groff <jgroff at apple.com> wrote:
>>> 
>>> I don't like the idea of some calls having wildly different semantics from others; it's difficult enough to tell what exactly a call might be doing already.
>> 
>> This isn’t particularly useful feedback.  Can you elaborate more on what your concern is, and how calls are unlike anything else in Swift that would have this potential problem?
>> 
>>> Since we also lack the more obvious static "Callable" protocol idea to give even well-typed call syntax to user-defined types, this also seems like it'd be easily abused for that purpose too.
>> 
>> Similarly, I’d love for you to elaborate on how the potential for abuse of this feature is different than anything else in Swift (e.g. operator overloading).  Potential for abuse hasn’t been a particularly guiding force in the design on Swift, and for good reasons.
>> 
>> I also don’t understand what you mean by a static Callable protocol.  I specifically address what I think you might mean in the “alternatives” part of the proposal, did you read that?
> 
> People have reasonably asked for the ability to make their own function-like types in the past, such that "myvalue(...)" behaves like sugar for "myvalue.call(...)" or something like that. In most cases, they still want to have type system control over what arguments and results their call operation produces. They don't really get that with this proposal; they lose all control over the arity and argument types. That may be what you want for calling into a dynamically-typed black hole, but it's not what you want in general. I fear that people would be willing to compromise their designs in order to get the sugar they want by contorting to fit this design.

+1.  This exact concern is the first thing that came to mind while reading this proposal.  

The general problem of interop with dynamic languages is an important one but a solution shouldn’t come at the cost of introducing syntactic sugar that is sub-optimal for native Swift code.

> 
>> 
>>> I think a much better general solution to the problem of "make dynamic systems interact with type systems" is something like F#'s type providers which lets you write your own importers that look at dynamic information from a database, dynamic language VM, or some other system and generate type information usable by the compiler.
>> 
>> Thanks! I wasn’t aware of type providers, I’ll investigate them.
>> 
>>> Integration at the importer level could let you produce more well-typed Swift declarations by looking at the runtime information you get by importing a Python module.
>> 
>> This is also addressed directly in the proposal.  I don’t want to add Python specific support to Swift.  The motivations are explained in the proposal.
> 
> I'm not suggesting a Python-specific feature, I'm suggesting that type providers could be a general framework for the kinds of problems you encounter trying to make dynamic systems work with Swift, including Python.
> 
> -Joe
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution