[Review] SE-0056: Allow trailing closures in `guard` conditions

Evolution Announcements
1

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 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?

+1

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

Yes.

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

Yes.

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

not applicable

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

Followed the mailing list thread and read the proposal.

···

On 01 Apr 2016, at 05:27, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

3

I would prefer the conditional statements to treat trailing closures
consistently, rather than allow this minor but inconsistent convenience. I
don't think this needs changing. I read the proposal and followed the list
discussion.

4

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions"
begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md

   - What is your evaluation of the proposal?

+1 for improving guard. As noted it does leverage an existing

inconsistency between guard and if/while/switch (e.g. else) so it isn't
really make things that more inconsistent. The use of else in guard exist
for good reasons.

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

It is close in my book.

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

I think so. I would like to see the modification of if/while/switch as

outlined in the alternates section to be more fully evaluated. It would
empower those constructs and bring things back into alignment.

···

On Thu, Mar 31, 2016 at 8:27 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

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

Fully read the proposal and followed the discussion.

5

What is your evaluation of the proposal?

-1 I admire the goal of making trailing closures usably in guard, but I do not like the inconsistency between guard and if. I also never liked the inconsistency with the else keyword in guard. Bother those reasons means that I’m worried that this will increase the cost of transforming guards into ifs, as can be quite frequent when refactoring code.

For example, transforming:

guard collection.contains { $0.predicate } else {
    return
}

Would require more modification:

if !collection.contains({ $0.predicate }) {
    return
}

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

I do not think so.

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

I think this proposal has the danger of adding inconsistency, which is opposite to the direction of simplification for Swift 3.0

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

Ruby uses keywords the conditional expression for the body of control structures (similar to guard’s else). Perhaps if Swift also adopted those would we be able to implement trailing closures in conditional expressions everywhere:

if condition then {
} else {
}

while condition do {
}

switch expression on {
}

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

A thorough read and long thought.

···

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

6

What is your evaluation of the proposal?

I think there is a lot of value to allowing trailing closures in the guard condition clause. However, not at the cost of inconsistency. We have reviewed many proposals over the last month that addressed consistency issues in the Swift language, and if I'm not mistaken, all of them have been accepted by the community, larger to eliminate the inconsistency.

Because of this, I think two of the alternatives stated by the proposal have credibility:
1) Eliminate the "else" keyword from the guard syntax.
2) Add keywords to "if", "while", "for", and "switch" to delineate the condition clause from the body of the statement.

The second alternative has more appeal, because it supports trailing closures without "heroics".

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

No.

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

No. Please don't add inconsistencies to the language, as we're just going to have to deal with it down the road.

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

Not in my experience.

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

In-depth study.

7

What is your evaluation of the proposal?

+1. I stumble on this quite often.

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

yes

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?

quick reading

···

On Mar 31, 2016, at 11:27 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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

8

Like others, I'm -1 on this due to added inconsistency between the guard and other control flow statements.

R+

···

Sent from my iPhone

On 01 Apr 2016, at 05:27, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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

9

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
What is your evaluation of the proposal?

+1 - I’m in favor of it.

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

Yes

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

Yes. The point of trailing closure syntax is to allow user-defined functions to look like natural control flow statements. This is especially true for guard and the omission of the capability is an obvious oversight. The arguments against it seem to be arguments against trailing closure syntax entirely which is a separate issue from this proposal. So long as trailing closure syntax exists it should be usable in a guard statement.

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

Reading the proposal and the various threads, plus some thinking time.

Russ

···

On Mar 31, 2016, at 8:27 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

10

+1. I feel this fits well with Swift, and the current inconsistency with other statements warrants the change.

···

On Mar 31, 2016, at 8:27 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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

11

What is your evaluation of the proposal?

+1. I like the rule of “don’t make me think”. If I write a piece of code that seems correct to me, why would the compiler “intentionally” stop me from accepting it? Just smooth out this rough edge and remove one scenario in which a compiler error stops me in my work for an error that’s not essential complexity.

Yes, the price of it is a slight inconsistency, as this won’t work with `if foo { … } {`. But I seriously doubt anyone would actually *see* this as inconsistent. Most programmers would just not be stopped for writing `guard foo { … } else`, and would never notice. No error, no problem :) It’s just that now there’s one less place that is a potential error generator ;)

So, yeah, it seems like a fairly straightforward improvement. Not perfect as it doesn’t solve anything, but more like “Why not?"

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?

Sure, why not ;)

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

A quick reading, and I’ve roughly followed the initial discussion on the pitch as well.

Best,
— Radek

···

On 01 Apr 2016, at 05:27, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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

12

+1 with the same evaluation as Sebastian Hagedorn

···

On Friday, 1 April 2016, Sebastian Hagedorn via swift-evolution < swift-evolution@swift.org> wrote:

   - What is your evaluation of the proposal?

+1

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

Yes.

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

Yes.

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

not applicable

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

Followed the mailing list thread and read the proposal.

On 01 Apr 2016, at 05:27, Douglas Gregor <dgregor@apple.com > <javascript:_e(%7B%7D,'cvml','dgregor@apple.com');>> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions"
begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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-announce mailing list
swift-evolution-announce@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution-announce@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

--
-- Howard.

13

What is your evaluation of the proposal?

I think there is a lot of value to allowing trailing closures in the guard condition clause. However, not at the cost of inconsistency. We have reviewed many proposals over the last month that addressed consistency issues in the Swift language, and if I'm not mistaken, all of them have been accepted by the community, larger to eliminate the inconsistency.

Because of this, I think two of the alternatives stated by the proposal have credibility:
1) Eliminate the "else" keyword from the guard syntax.
2) Add keywords to "if", "while", "for", and "switch" to delineate the condition clause from the body of the statement.

The second alternative has more appeal, because it supports trailing closures without "heroics".

It have been mentioned multiple times that allowing trailing closure only for guard is creating an inconsistency, but these keywords already are inconsistent with the each other (beside the presence of the 'trailing' else keyword) on the variable scoping:

- guard let: outer scope immutable variable
- if let: inner scope immutable variable
- for: inner scope immutable variable without let keyword

Consistency is good, but since each keywords are not for the exact same thing, it is normal to see some variances. Like the global scope of the immutable variable created by guard; as per the intent of the keyword, or its trailing else keyword; needed to clarify that what follow is for, for lack of better word, the 'else' case.

So as long as such inconsistency have a "raison d'être", that they have been designed and are not an oversight; there should be no reason to not allow them.

Dany

···

Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution <swift-evolution@swift.org> a écrit :

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

No.

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

No. Please don't add inconsistencies to the language, as we're just going to have to deal with it down the road.

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

Not in my experience.

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

In-depth study.

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

14

Interesting idea to put keywords in the other statements so that they can
also use trailing closures!

···

On Sunday, 3 April 2016, Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> wrote:

   - What is your evaluation of the proposal?

+1. I stumble on this quite often.

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

yes

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

quick reading

   -

On Mar 31, 2016, at 11:27 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions"
begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

15

One idea related to this `for...do` syntax--maybe this will satisfy
some objections listed in the proposal:

Currently, Swift has optional semicolons. In the same spirit, suppose
control statements have optional colons, like this: `for eachValue in
theValues: { code }`. All current syntax continues to work, but you
could then use closures in control statements by putting in a colon
after the expression.

No new keywords would be needed, things would be very terse, and the
syntax would be unambiguous.

I'm proposing this because, even though the `for...do` idea is
interesting, I'm -1 as it is because it can create other ambiguities.
For example, imagine that you have `frobnicate(_: Int)` and
`frobnicate(_: Int, compare: (Int) -> Bool)`. Which function is being
called if you see the following?

for i in frobnicate(1) {
// code
}
do {
// code
}

Either you would need new rules about line breaks (adding new
inconsistencies between control statements, because `if...else` has
very flexible rules about line breaks), or else the meaning of the
code above would change if the lines that followed were:

catch {
// code
}
···

On Sun, Apr 3, 2016 at 10:20 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

Although I use trailing closures a lot less now, I think I’m a +1 anyway for
consistency’s sake.

I actually really like the idea of having trailing keywords in loops and if
statements, these needn’t be required (except where a trailing closure is
used) but for example it means I could do a fully natural language loop
like:

for eachValue in theValues do { … }

Which is very, very clear on what’s happening there and I like the
consistency of every block having a kind of type (do, else, defer, catch
etc.). That said it’s probably grounds for a separate, supplementary
proposal once guard has this capability? Of course if it can be done at the
same time that’d be great too, as the implementation of this proposal should
assume that if/while will gain the same ability at some point once we decide
how to do it.

On 3 Apr 2016, at 13:44, Howard Lovatt via swift-evolution > <swift-evolution@swift.org> wrote:

Interesting idea to put keywords in the other statements so that they can
also use trailing closures!

On Sunday, 3 April 2016, Ilya Belenkiy via swift-evolution > <swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?

+1. I stumble on this quite often.

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

yes

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?

quick reading

On Mar 31, 2016, at 11:27 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions"
begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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

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

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

16

Although I use trailing closures a lot less now, I think I’m a +1 anyway for consistency’s sake.

I actually really like the idea of having trailing keywords in loops and if statements, these needn’t be required (except where a trailing closure is used) but for example it means I could do a fully natural language loop like:

  for eachValue in theValues do { … }

Which is very, very clear on what’s happening there and I like the consistency of every block having a kind of type (do, else, defer, catch etc.). That said it’s probably grounds for a separate, supplementary proposal once guard has this capability? Of course if it can be done at the same time that’d be great too, as the implementation of this proposal should assume that if/while will gain the same ability at some point once we decide how to do it.

···

On 3 Apr 2016, at 13:44, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

Interesting idea to put keywords in the other statements so that they can also use trailing closures!

On Sunday, 3 April 2016, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What is your evaluation of the proposal?

+1. I stumble on this quite often.

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

yes

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?

quick reading

On Mar 31, 2016, at 11:27 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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/0056-trailing-closures-in-guard.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 <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

17

If I understand you correctly, you think adding keywords represents an inconsistency. However, I think it would add considerable consistency and utility to the Swift language. Yes, it would make it inconsistent with the generations of C-like languages that have come before it. However, I think we've already taken considerable steps from away from C-like languages; for example, removing C-like for-loop syntax and unary increment/decrement operators.

-Patrick

···

On Apr 3, 2016, at 11:44 AM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

What is your evaluation of the proposal?

I think there is a lot of value to allowing trailing closures in the guard condition clause. However, not at the cost of inconsistency. We have reviewed many proposals over the last month that addressed consistency issues in the Swift language, and if I'm not mistaken, all of them have been accepted by the community, larger to eliminate the inconsistency.

Because of this, I think two of the alternatives stated by the proposal have credibility:
1) Eliminate the "else" keyword from the guard syntax.
2) Add keywords to "if", "while", "for", and "switch" to delineate the condition clause from the body of the statement.

The second alternative has more appeal, because it supports trailing closures without "heroics".

It have been mentioned multiple times that allowing trailing closure only for guard is creating an inconsistency, but these keywords already are inconsistent with the each other (beside the presence of the 'trailing' else keyword) on the variable scoping:

- guard let: outer scope immutable variable
- if let: inner scope immutable variable
- for: inner scope immutable variable without let keyword

Consistency is good, but since each keywords are not for the exact same thing, it is normal to see some variances. Like the global scope of the immutable variable created by guard; as per the intent of the keyword, or its trailing else keyword; needed to clarify that what follow is for, for lack of better word, the 'else' case.

So as long as such inconsistency have a "raison d'être", that they have been designed and are not an oversight; there should be no reason to not allow them.

Dany

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

No.

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

No. Please don't add inconsistencies to the language, as we're just going to have to deal with it down the road.

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

Not in my experience.

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

In-depth study.

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

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

18

Although I use trailing closures a lot less now, I think I’m a +1 anyway for consistency’s sake.

I actually really like the idea of having trailing keywords in loops and if statements, these needn’t be required (except where a trailing closure is used) but for example it means I could do a fully natural language loop like:

  for eachValue in theValues do { … }

This is actually kind of bizarre. Here we are trying to invent new syntax so that the trailing closure can be used in if/while conditions and for sequences. However, there is already a perfectly good syntax for putting closures in these positions: put the closure in the parentheses of the function call. Are people really so desperate to use trailing closures everywhere that we have to add new keywords to the language? I don’t think they are.

I like the consistency of every block having a kind of type (do, else, defer, catch etc.).

That is a rabbit hole down which you probably shouldn't go. If we go down the route of blocks having a “type”, the current situation in Swift becomes somewhat inconsistent. I would argue that the `else` block on a `guard` is of a different type to the `else` block on an `if`. If anything, the `else` block of an `if` is closer to the `then` block. Also, would you allow the `do` block in a `for` or `while` to have a `catch` block following it? If not, then these blocks are different to the existing bare `do` block.

···

On 3 Apr 2016, at 17:20, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

19

Although I use trailing closures a lot less now, I think I’m a +1 anyway for consistency’s sake.

I actually really like the idea of having trailing keywords in loops and if statements, these needn’t be required (except where a trailing closure is used) but for example it means I could do a fully natural language loop like:

  for eachValue in theValues do { … }

This is actually kind of bizarre. Here we are trying to invent new syntax so that the trailing closure can be used in if/while conditions and for sequences. However, there is already a perfectly good syntax for putting closures in these positions: put the closure in the parentheses of the function call. Are people really so desperate to use trailing closures everywhere that we have to add new keywords to the language? I don’t think they are.

While I kind of agree (and personally prefer the use of parenthesis in most places anyway) it’s an inconsistency to be unable to use them I think. While It’s understandable from a parsing/ambiguity perspective, it’s not really intuitive.

I like the consistency of every block having a kind of type (do, else, defer, catch etc.).

That is a rabbit hole down which you probably shouldn't go. If we go down the route of blocks having a “type”, the current situation in Swift becomes somewhat inconsistent. I would argue that the `else` block on a `guard` is of a different type to the `else` block on an `if`. If anything, the `else` block of an `if` is closer to the `then` block. Also, would you allow the `do` block in a `for` or `while` to have a `catch` block following it? If not, then these blocks are different to the existing bare `do` block.

Actually that’s not quite what I meant by “type”; while there is a case to be made for unifying these more (else and catch on loops for example) I just meant more along the lines that “do” would always group the main branch, “else” indicates an alternative path if a condition isn’t met and so-on. For the short term however this would just be a case of allowing do on the end to eliminate ambiguity and thus allow trailing closures, but in the long term it could be explored further.

···

On 4 Apr 2016, at 15:49, Jeremy Pereira <jeremy.j.pereira@googlemail.com> wrote:

On 3 Apr 2016, at 17:20, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

20

I agree.
While I'm a big proponent of trailing closures to create DSL like control constructs and prefer them over nesting closures within parentheses I don't think it is a good idea to mix such DSL like control constructs with existing control constructs as this would not increase readability but rather decrease it (compare e.g. the example given by Xiaodi).

Therefore I'm -1 on this proposal and think it's fine having to use parentheses instead of trailing closures in such cases.

-Thorsten

···

Am 04.04.2016 um 16:49 schrieb Jeremy Pereira via swift-evolution <swift-evolution@swift.org>:

On 3 Apr 2016, at 17:20, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

Although I use trailing closures a lot less now, I think I’m a +1 anyway for consistency’s sake.

I actually really like the idea of having trailing keywords in loops and if statements, these needn’t be required (except where a trailing closure is used) but for example it means I could do a fully natural language loop like:

   for eachValue in theValues do { … }

This is actually kind of bizarre. Here we are trying to invent new syntax so that the trailing closure can be used in if/while conditions and for sequences. However, there is already a perfectly good syntax for putting closures in these positions: put the closure in the parentheses of the function call. Are people really so desperate to use trailing closures everywhere that we have to add new keywords to the language? I don’t think they are.