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

I'm surprised this could lead to confusion. I have never encountered any errors relating to the current behaviour. That the presence of brackets could mean a parameter list, or a function that takes a parameter, I could see as an extension of tuple splat, providing flexibility. However, since tuple splat has been removed for now, I understand why this might need rethinking.

Why this means we have to add brackets to functions taking a single type, where there is no ambiguity or possibility for confusion, I don't understand at all.

Tuple splat originally allowed generic types to use tuple parameters as generic parameter lists to functions, allowing great syntax for things like notification forwarding (see frameworks such as ObservableSwift), and I was sad to see that go. With Swift 3 I'll just have to live with double-bracketed parameter lists.

I was in favour of keeping tuple splat, but that was more of an edge case. I find myself using single-parameter function types regularly, and love what support for functional programming Swift provides. I am definitely in favour of allowing the bracketless syntax.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <8597386C-FE51-4156-9ECD-CEB11579C05C@apple.com>

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:

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

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:

Reply text

Other replies
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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

Thank you,

Doug Gregor

Review Manager

------------- End Message -------------

From James F