<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=""><div><blockquote type="cite" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md</a></blockquote><br class=""></div><blockquote type="cite" class="">What is your evaluation of the proposal?<br class=""></blockquote><br class="">-1, I'm mildly against but against.<div class=""><br class=""></div><div class="">In light of the observation (<a href="http://permalink.gmane.org/gmane.comp.lang.swift.evolution/15577" class="">http://permalink.gmane.org/gmane.comp.lang.swift.evolution/15577</a>) that we don't need Swift's type system to distinguish between function arity and a singular tuple argument, I don't think it's a good idea to add parentheses to the game.</div><div class=""><br class=""></div><div class="">Instead, I propose (in the above mail) to extend the notion of function name to always cover its argument labels.<br class=""><br class=""><div class=""><blockquote type="cite" class="">Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote></div><div class=""><br class=""></div><div class="">No. (Even in the current state of things, I don't think we should require the parentheses except maybe to disambiguate tuples.)</div><div class=""><br class=""><blockquote type="cite" class="">Does this proposal fit well with the feel and direction of Swift?<br class=""></blockquote></div><div class=""><br class=""></div><div class="">When it comes to the core team's idea of function types, I don't have a good sense of direction where you want to take the argument list. However, I don't think introducing (or canonicalising) a new pseudo type for function argument lists is a good direction for Swift to take, as it would later make higher-level programming demand even more complex syntaxes to deal with the said function types (I'll take C++ as an alerting example).</div><div class=""><br class=""></div><div class="">As shown, we can represent a function's argument list as an unlabelled n-tuple (including n=1), and doing so can come with no loss in generality nor added ambiguity.</div><div class=""><br class=""><blockquote type="cite" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></blockquote></div><br class="">Haskell only has unary functions and functions extensively use currying (`<font face="Menlo" class=""><span style="font-size: 11px;" class="">A -> B -> R</span></font>`). But you can also pass arguments in a tuple if you seriously don't want currying (`<font face="Menlo" class=""><span style="font-size: 11px;" class="">(A, B) -> R</span></font>`). Like in Swift, parentheses are required together with the comma to create tuples. A type like `<font face="Menlo" class=""><span style="font-size: 11px;" class="">(A) -> B</span></font>` is allowed but synonymous to `<font face="Menlo" class=""><span style="font-size: 11px;" class="">A -> B</span></font>`. A crucial difference to Swift is that Haskell's functions are more like Swift's function variables (which is what I call the identifier you bind a closure to), with only a base name; whereas Swift cleverly uses argument labels to increase legibility at the call site.</div><div class=""><br class=""></div><div class="">Scala is much like Haskell in this regard, while currying isn't that extensive, it also leaves the parentheses optional (and often omitted) around single-type argument lists.</div><div class=""><br class=""></div><div class="">In C++, the syntax for n-argument functions gets crazy quickly, especially when the return type is also a function. What gets even more crazy is the (variadic) template code needed to program in terms of functions. And C++ also doesn't deal with argument labels!</div><div class=""><br class=""></div><div class="">This proposal feels to me like a tiny step towards C++'s direction. Not harmful but unnecessary.<br class=""><br class=""><div class=""><blockquote type="cite" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></blockquote></div><br class=""><div class="">In-depth.</div><div class=""><br class=""></div><div class="">— Pyry</div></div><div class=""><br class=""></div></body></html>