> 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 >> >> <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. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
