Sent from my iPad
> On Nov 10, 2017, at 7:41 PM, Chris Lattner <sa...@nondot.org> wrote: > > >> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>>> >>>> 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. >>> >>> As I mentioned, this is directly addressed in the writeup. Here’s the link: >>> https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d#staticly-checking-for-exact-signatures >> >> That discusses why you didn’t include it in the present proposal but I think >> it’s reasonable to oppose adding a dynamic callable feature prior to a more >> Swifty static callable. > > Why? One does not preclude the other. For exactly the reason Joe articulates. Some people will use what the language offers to get the syntax they desire even if it sacrifices type safety. If we’re going to have first-class callable types in Swift (I think it’s a great idea) type safety for native code should be prioritized over syntactic convenience for dynamic language interop. We can have both, but the former should come first IMO. Setting this aside, I’m very curious to hear whether type providers influence your thinking after you’ve had a chance to look into them. I have always thought they were very cool. > > -Chris >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
