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

[Xiaodi Wu]

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 at 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 at 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 at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> -- Howard.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>