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

Evolution Announcements
1

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

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:

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

2

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@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
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
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
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

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Hello,

Here are two things to improve the proposal and make it more clear:

I'd like the Motivation section to be much more explicit. I get the argument of ambiguity, OK, but I don't see the problems it creates. I personally did not have any trouble yet, and this section does not enlighten me. Do we create problems out of thin air, here?

The History section looks irrelevant to me: the visible shape of a language does not have to reflect its inner implementation.

Gwendal Roué

···

Le 26 avr. 2016 à 06:22, Douglas Gregor via swift-evolution <swift-evolution@swift.org> a écrit :

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
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
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
Reply text

Other replies
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
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

My evaluation mostly depends on the degree of simplification that can be archived, so it's fine for me to let those decide who know best.
Skipping parentheses is convenient, but requiring them won't be that painful — and in case the latter statement is wrong, my general impression is we are in a "slim-down" phase now, and re-adding something back in Swift 3+ won't break anything.

Nonetheless, I like the thought of "all functions take a single parameter", so I'm curious about the history of this deprecated principle.
It is relevant to many topics on the list, and I've never seen a detailed explanation about the pros and cons:
Instead of removing tuple splat, we could as well talk about discarding varargs and inout-parameters… (I don't think default args and internal/external labels are showstoppers here).

Tino

5

What is your evaluation of the proposal?

A somewhat reluctant +1. I like the sugar but Chris makes a good case about the ambiguities and the move away from functional tradition. I am a bit sad about the need for parentheses but it seems like maybe it's for the best.

I also must admit that increased consistency of adding the parentheses will probably make the language a bit easier to learn for those not coming from a functional background.

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

It cleans up function type syntax to match other recent changes.

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

Yes, especially Swift 3 direction.

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

I really like the very clean syntax of functional languages which is why I am a little bit disappointed to see us add what looks like clutter when seen from a functional perspective.

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

Participated in the original thread, read the proposal and all replies, and gave some thought to the balance of aesthetics and clarity (especially removing ambiguity).

···

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

6

+1 from me. But IMO we need to discuss the question regarding parentheses for arguments in closure declaration.

···

On 26.04.2016 7:22, Douglas Gregor via swift-evolution 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

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

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

    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

    https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

  • 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

8

+1.

I’ve given this a lot of thought. I always put parentheses in, so this wouldn’t really affect me. Bigger picture though I thought back on what made us not require self usage, and I feel like this proposal could be rejected for similar reasons. However, I’ve never been confused by the self syntax, but not including parenthesis has led to some mixups when reading an API. I’m probably not the only one that has happened to.

···

On Apr 25, 2016, at 9:22 PM, Douglas Gregor via swift-evolution <swift-evolution@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
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
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
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

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

I’m going to play Devil’s advocate here and ask why not just pull out the parens for function types?

Int, Int -> Int // Two argument function type
(Int, Int) -> Int // Single tuple argument function type

vs

(Int, Int) -> Int // Two argument function type
((Int, Int)) -> Int // Single tuple argument function type

I’ll admit that

let x: Int, Int -> Int

looks okay, but

let x: arg1: Int, arg2: Int -> Int

does not look great compared to

let x: (arg1: Int, arg2: Int) -> Int

However, I don’t think it’s an inconsistent rule to require parenthesis when argument labels are specified. Indeed, this behavior is perfectly consistent with current closure syntax. e.g. { x, y -> Int in /* code */ }

Named tuples would be:

let x: ((arg1: Int, arg2: Int)) -> Int

Which has the double parens, but this is a more infrequent situation.

Tyler

···

On Apr 25, 2016, at 9:22 PM, Douglas Gregor via swift-evolution <swift-evolution@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
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
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
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

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

  • What is your evaluation of the proposal?

I think this change is overly fussy, but not the end of the world.

I enjoy this convenience, but I can live without it. I hope that, when the dust settles from all our parameter changes, we can reintroduce it in some form.

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

It seems insignificant to me, but I support small syntax clean-ups in general.

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

Arguably it does, at least for the current parameter-handling retrenchment.

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

N/A.

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

Participated in previous discussion.

···

--
Brent Royal-Gordon
Architechies

11

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\) 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

12

Fair enough. This is one of many recent proposals which are about cleaning up minor inconsistencies in the language, not because they cause excessive practical usage problems, but because they are wrong for the long term shape of the language.

Swift 3 will necessarily be a majorly source breaking change, so we’re trying to pack other source breaking changes into it. We almost certainly would not make a change like this in Swift 4 (where we will be much more adverse to source breaking changes), and would instead have to live with the inconsistency forever. As such, this is a “now or never” sort of thing.

-Chris

···

On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Here are two things to improve the proposal and make it more clear:

I'd like the Motivation section to be much more explicit. I get the argument of ambiguity, OK, but I don't see the problems it creates. I personally did not have any trouble yet, and this section does not enlighten me. Do we create problems out of thin air, here?

13

[[iOS messageWithData:ideas] broadcast]

···

On 26 Apr 2016, at 07:28, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

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:

Agreed, the exception for the parameter list in a closure declaration should be gone too potentially, I do not see a very convincing case why we should keep it. Does it solve some particular problem now in its current form?

14

I was expecting something like that.

I personally have no problem with changes that the *language implementers* see as necessary. You know better, after all. I can imagine how the grammar inconsistencies we're talking about here belong to a general maintenance problem.

I'll just hope that Swift won't become too inflexible, and that you'll figure out a way to protect the warm feeling that brought early Swift users in. And I'm targeting the "should we require" questions of the "Related questions" section of the proposal :-)

Gwendal

···

Le 26 avr. 2016 à 07:17, Chris Lattner <clattner@apple.com> a écrit :

On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Here are two things to improve the proposal and make it more clear:

I'd like the Motivation section to be much more explicit. I get the argument of ambiguity, OK, but I don't see the problems it creates. I personally did not have any trouble yet, and this section does not enlighten me. Do we create problems out of thin air, here?

Fair enough. This is one of many recent proposals which are about cleaning up minor inconsistencies in the language, not because they cause excessive practical usage problems, but because they are wrong for the long term shape of the language.

15

Hi David,

To be clear, this proposal is not about changing closure expressions, it was just a FAQ, and the section at the end is simply my personal opinion. Changing closure expression syntax would be a separate proposal.

-Chris

···

On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

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:

16

() is also used in type syntax for tuples, so without this requirement, (Int, Int) -> T is ambiguous between having two Int arguments or having one tuple argument.

-Joe

···

On Apr 26, 2016, at 3:07 PM, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:

I can't see that it would create any ambiguities to not use parens.

17

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
> 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
> 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
> 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
>
> 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

18

@Chris, I believe you should add your reply to the proposal itself.

···

On 26.04.2016 8:17, Chris Lattner via swift-evolution wrote:

On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Here are two things to improve the proposal and make it more clear:

I'd like the Motivation section to be much more explicit. I get the argument of ambiguity, OK, but I don't see the problems it creates. I personally did not have any trouble yet, and this section does not enlighten me. Do we create problems out of thin air, here?

Fair enough. This is one of many recent proposals which are about cleaning up minor inconsistencies in the language, not because they cause excessive practical usage problems, but because they are wrong for the long term shape of the language.

Swift 3 will necessarily be a majorly source breaking change, so we’re trying to pack other source breaking changes into it. We almost certainly would not make a change like this in Swift 4 (where we will be much more adverse to source breaking changes), and would instead have to live with the inconsistency forever. As such, this is a “now or never” sort of thing.

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

19

- What is your evaluation of the proposal?

I don't like it but +1. The possible ambiguity is somewhat compelling. I
actually think that, if this is accepted, it should be applied to closures
as well.

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

I am not sure.

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

I am not sure

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

N/A

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

I read it when it first showed up and have thought about it since while
writing and reading swift.

···

On Thu, Apr 28, 2016 at 4:19 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

>
https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

> • What is your evaluation of the proposal?

I think this change is overly fussy, but not the end of the world.

I enjoy this convenience, but I can live without it. I hope that, when the
dust settles from all our parameter changes, we can reintroduce it in some
form.

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

It seems insignificant to me, but I support small syntax clean-ups in
general.

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

Arguably it does, at least for the current parameter-handling retrenchment.

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

N/A.

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

Participated in previous discussion.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

20

I understand exactly what you mean. Perhaps your concern is a result of the character of many of these recent proposals: because we’re trying to get things settled for Swift 3, we’re hyper-focused on front-loading the “things we want to take away”, rather than spending time on sugar and other things that make the language feel more nice. The rationale for this approach is sound IMO (sugar can be added at any time later) but I can understand how it would feel like we’re "taking away” without “giving anything back” in this respect.

-Chris

···

On Apr 25, 2016, at 10:48 PM, Gwendal Roué <gwendal.roue@gmail.com> wrote:

Le 26 avr. 2016 à 07:17, Chris Lattner <clattner@apple.com> a écrit :

On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Here are two things to improve the proposal and make it more clear:

I'd like the Motivation section to be much more explicit. I get the argument of ambiguity, OK, but I don't see the problems it creates. I personally did not have any trouble yet, and this section does not enlighten me. Do we create problems out of thin air, here?

Fair enough. This is one of many recent proposals which are about cleaning up minor inconsistencies in the language, not because they cause excessive practical usage problems, but because they are wrong for the long term shape of the language.

I was expecting something like that.

I personally have no problem with changes that the *language implementers* see as necessary. You know better, after all. I can imagine how the grammar inconsistencies we're talking about here belong to a general maintenance problem.

I'll just hope that Swift won't become too inflexible, and that you'll figure out a way to protect the warm feeling that brought early Swift users in. And I'm targeting the "should we require" questions of the "Related questions" section of the proposal :-)