> • 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
