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

[David Hart]

I have several questions/issues in this new iteration:

• Why does DynamicCallableWithKeywordsToo inherit from DynamicCallable? For an interop layer for Python-style languages, we would be interested in providing conformance to DynamicCallableWithKeywordsToo (like you did in your example), but that would force us to provide an implementation for the keyword-less function that just calls the other overload with empty labels. Seems unnecessary.
• Why is the DynamicCallableKeywordedMethod protocol not included with the two others? The way it is presented in the proposal, it almost feels like an afterthought and not a full-fledged part of the proposal.

In terms of bike-shedding, how about:

DynamicCallable
LabeledDynamicCallable
DynamicMemberCallable

> On 21 Nov 2017, at 07:10, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Nov 20, 2017, at 10:07 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hi All,
>> 
>> I’ve significantly revised the ‘dynamic callable’ pitch, here’s a second edition:
> 
> Ugh, the actual correct link is:
> https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d
> 
>> 
>> I’ve incorporated a bunch of feedback from the first round of discussion:
>> 
>> - I’ve significantly increased the motivation section, talking about the value of solving this problem, and explaining why IMO an “ObjC Importer” approach is a bad idea.
>> - I’ve made it possible for (e.g.) a Javascript client to implement support for this while statically rejecting keyword arguments, but allow (e.g.) a Python implementation to accept them.
>> - I’ve expanded the model to support the name lookup requirements of Ruby and other smalltalk’y languages that require a base name + argument labels be present to resolve calls.
>> - I’ve expanded the alternatives section to explain why statically resolvable callables are orthogonal to this proposal and already pretty well served by Swift today.
>> - I’ve expanded the alternatives section to talk about F# type providers, explaining why they don’t solve this problem and are an interesting follow-on refinement to consider after taking this proposal (or something like it).
>> 
>> That said, there is at least one specific obviously bad thing about this proposal: the name “DynamicCallableWithKeywordsToo” which I appreciate help on.
>> 
>> If you’re interested in this topic, I’d really appreciate it if you’d read the new draft of the proposal.  It is significantly different than the original draft.  I welcome suggestions for improvements to the proposal, and insight into anything that is unclear or insufficiently motivated.
>> 
>> Thanks!
>> 
>> -Chris
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution