<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 1:19 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 10:51 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">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.<br class=""><br class="">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?<br class=""></blockquote><br class="">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. </div></div></blockquote><div class=""><br class=""></div><div class="">As I mentioned, this is directly addressed in the writeup. Here’s the link:</div><div class=""><a href="https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d#staticly-checking-for-exact-signatures" class="">https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d#staticly-checking-for-exact-signatures</a></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>