I agree with David.
I don’t think I’ve ever omitted parenthesis in the argument list of a closure;
not only that, but I think that omitting them in that case *reduces* clarity,
making the closure harder to parse visually.
Nicola
> What is your evaluation of the proposal?
> I reluctantly agree with the proposal with the following caveat: I do not
> agree with the rationale to support being able to choose to omit the () for
> the parameter list of the closure declaration.
>
> I see no cohesive argument that says that the parens should be required in
> some cases but not in others when talking about parameter lists.
>
> I believe the proposal should be amended that the following should be the
> only allowable forms:
>
> y = x.sorted { (lhs : Int, rhs : Int) ->Bool in rhs<lhs }
> y = x.sorted { (lhs, rhs) in rhs<lhs }
> y = x.sorted { $1<$0 }
>
> I’ve bolded the change above, today this is allowable:
>
> y = x.sorted { lhs, rhs in rhs<lhs }
>
> I’ve read the argument about why it’s ok to elide the parens here, I simply
> disagree with the author’s premise that this is a structurally significant
> different form. Not requiring the parens for this parameter list begs the
> question why other forms require them and provides a similar ambiguity of
> whether the closure takes two parameters or a single tuple parameter from
> both of these valid syntaxes today:
>
> y = x.sorted { lhs, rhs in rhs<lhs }
> y = x.sorted { (lhs, rhs) in rhs<lhs }
>
> I don’t see how this is fundamentally different than the example in the
> “Motivation” section:
>
> (Int, Float) ->Int // Takes two arguments, or takes one two-argument tuple?
>
> While I will concede that `(lhs, rhs)` is not a valid tuple declaration, I’d
> still argue that it’s too subtle of a difference to be used a primary means
> of justification. If we are going to remove the ambiguity, let’s remove it
> for all parameter list scenarios.
>
> Is the problem being addressed significant enough to warrant a change to
> Swift?
> Potentially.
>
> Does this proposal fit well with the feel and direction of Swift?
> Yes.
>
> How much effort did you put into your review? A glance, a quick reading, or
> an in-depth study?
> I participated in the original discussion thread as well as tested out many
> different combinations function and closure syntax in the Swift Playground.
>
> -David
>
>
>
> > On Apr 25, 2016, at 9:22 PM, Douglas Gregor via
> > swift-evolution<swift-evolution at swift.org>wrote:
> >
> > Hello Swift community,
> >
> > The review of SE-0066 "Standardize function type argument syntax to require
> > parentheses" begins now and runs through May 2, 2016. The proposal is
> > available here:
> >
> > 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>
> > Reviews are an important part of the Swift evolution process. All reviews
> > should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution<https://lists.swift.org/mailman/listinfo/swift-evolution>
> > or, if you would like to keep your feedback private, directly to the review
> > manager. When replying, please try to keep the proposal link at the top of
> > the message:
> >
> > Proposal link:
> >
> > 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>
> > Reply text
> >
> > Other replies
> > <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What
> > goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> > through constructive criticism and, eventually, determine the direction of
> > Swift. When writing your review, here are some questions you might want to
> > answer in your review:
> >
> > What is your evaluation of the proposal?
> > Is the problem being addressed significant enough to warrant a change to
> > Swift?
> > Does this proposal fit well with the feel and direction of Swift?
> > If you have used other languages or libraries with a similar feature, how
> > do you feel that this proposal compares to those?
> > How much effort did you put into your review? A glance, a quick reading, or
> > an in-depth study?
> > More information about the Swift evolution process is available at
> >
> > https://github.com/apple/swift-evolution/blob/master/process.md<https://github.com/apple/swift-evolution/blob/master/process.md>
> > Thank you,
> >
> > Doug Gregor
> >
> > Review Manager
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
