[swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[Michael Peternell]

> 	• What is your evaluation of the proposal?

-10
strongly against it. I can't see that it would create any ambiguities to not use parens. In all cases, I can see the meaning of a function type, e.g. Int -> String is a function that takes an Int and produces a String; (Int) -> String doesn't look better to me. Float -> Float looks like a mathematical function, but (Float) -> Float just looks strange.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

I don't see a problem, so NO.

> 	• Does this proposal fit well with the feel and direction of Swift?

No, because in most places Swift allows omitting unneeded syntax, e.g. one can write { $0 + $1 } instead of {a,b in a+b}. It's not always the case that shorter=better, but I cannot imagine how I would explain the reason for the (parenthesis requirement) to someone who does not know anything about programming language theory. And the general rule that "all function argument lists should be surrounded by parentheses" feels arbitrary. I think an ordinary language user doesn't even have a concept of an "argument list", but a concept of an "argument declaration list" and a concept of a "one-arg function" and a concept of a "two-arg function", and no names for any of this stuff.

"Why do we need parens around here now?" - "Because it's more *consistent* that way"
"Why don't we have milk for the coffee anymore?" - "Because it's more *consistent* that way. We have only one type of coffee now." - "haha" ;)

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I wouldn't call it a "feature". I know only one language that uses a similar (function-type-syntax-) style, and that is Haskell. Haskell doesn't require any parentheses, except for disambiguating the parse tree. I know Swift and Haskell are quite different, but moving away from functional programming is a non-goal for me; there must be a better reason for justifying the proposal.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal, and all mails on the Swift evolution list (regarding the proposal), and I really tried to see the advantages of the proposal, but I still cannot see them. It doesn't matter though, because most people on this mailing list seem to like it.

The only semi-convincing argument I remember was that it would simplify the grammar. Making the development experience for the language designers nicer has some value, of course, but I hope there will be a better way to solve this issue.

-Michael