[swift-evolution] [Pitch #2] Introduce user-defined dynamically "callable" types
Chris Lattner
sabre at nondot.org
Tue Nov 21 00:07:00 CST 2017
Hi All,
I’ve significantly revised the ‘dynamic callable’ pitch, here’s a second edition:
https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
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
More information about the swift-evolution
mailing list