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@swift.org> wrote: > > > >> On Nov 20, 2017, at 10:07 PM, Chris Lattner via swift-evolution >> <swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
