> https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md> > What is your evaluation of the proposal?
-1, I'm mildly against but against. In light of the observation (http://permalink.gmane.org/gmane.comp.lang.swift.evolution/15577 <http://permalink.gmane.org/gmane.comp.lang.swift.evolution/15577>) 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. Instead, I propose (in the above mail) to extend the notion of function name to always cover its argument labels. > Is the problem being addressed significant enough to warrant a change to > Swift? No. (Even in the current state of things, I don't think we should require the parentheses except maybe to disambiguate tuples.) > Does this proposal fit well with the feel and direction of Swift? 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). 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. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? Haskell only has unary functions and functions extensively use currying (`A -> B -> R`). But you can also pass arguments in a tuple if you seriously don't want currying (`(A, B) -> R`). Like in Swift, parentheses are required together with the comma to create tuples. A type like `(A) -> B` is allowed but synonymous to `A -> B`. 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. 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. 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! This proposal feels to me like a tiny step towards C++'s direction. Not harmful but unnecessary. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? In-depth. — Pyry
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
