Sent from my iPad
> On Nov 10, 2017, at 12:51 PM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On Nov 10, 2017, at 10:41 AM, Chris Lattner <sa...@nondot.org> wrote: >> >> On Nov 10, 2017, at 10:03 AM, Joe Groff <jgr...@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@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
