Add a proposal for guard-catch

[khanlou]

This pull request adds a proposal for a guard/catch construct for the language.

It would allow code to use throwing functions and handle errors fully, without straying from a happy path. do/catch can be a bit heavy-handed sometimes, and it would be nice to be able to handle throwing functions without committing to all the nesting and ceremony of do/catch.

This proposal was first discussed on the Swift Evolution list in the [Pitch] Guard/Catch thread.

[hhanesand]

This is something I feel that is sorely lacking from Swift...

I'm very excited to see a formalized proposal for this 👍

[tapoton]

Why is described problem an issue?

We are allowed to initialize constant after the declaration if it's guaranteed to be initialized before it's used. It gives even more flexibility here, still being readable, clean and free from excessive nesting.

For example:

func nonthowingFunc() {
    
    let value: Int
    
    do {
        
        value = try throwingFunc()
        
    } catch {

        print(error)
        return
    }
    
    print(value)
}

Although, I agree that guard is much more obvious way to do such things in terms of swift.

[lattner]

Hi @khanlou,

We discussed this in the core team today and agreed that it is super desirable to solve this problem for swift developers, but there are significant design problems with the proposal: we consider it unacceptable for the interpretation of "guard let x = ..." to change based on whether it is followed by "else {}" or "catch {}". The contents of the condition of a guard/if shouldn't change this way. Further, building this into guard implies strongly that the "if" dual should be supported as well, which isn't actually desirable.

To reiterate my opinion on this, one way to express this is:

let bar = try foo() catch {
... statement that must not fallthrough
}

That said, this is just one option. There may be other ways to solve this problem that don't break consistency with the rest of the language.

In any case, please bring this back to the pitch phase on the swift-evolution list for more discussion. Once it converges to a new proposal, the core team will look at it again, and recommend an implementation to start when it looks good.

-Chris

btw, your podcast is great!

[khanlou]

@lattner —

Thank you for the kind words about the podcast, I'll pass them along to @cdzombak as well.

To me, the guard syntax is crucial, since it implies a scope exit. I think no matter what Swift construct we glom this feature onto, the idiomatic meaning of that construct is going to shift in some direction. To that end, maybe I can propose a meta-analysis of each approach and their pros and cons to the mailing list.

However, none of this matters, since, per the new rules for Swift 5 proposals, I'd have to provide an implementation, which is currently well beyond my abilities. Could you possibly expand on what you mean by "recommend an implementation"?

Soroush

PS: you should come on the show sometime!

[lattner]

Because proposals must be implemented before review, the core team is pre-reviewing proposals to provide guidance of whether they are conceptually plausible for inclusion in swift. This is to avoid the problem of someone spending a bunch of time implementing something, then the core team saying "no, that's a bad idea"

[hartbit]

@khanlou To be clear: proposals need an implementation but its not important who implements it. The core team has also implied that they might help pair proposal authors with implementors, so I wouldn't worry about that part. Btw, love the podcast too ;)

@lattner I'll have more space to discuss this on the mailing-list when the proposal comes back for discussion, but I also believe that the guard statement is the right solution specifically because it forces a scope exit. Doing anything else would muddy the semantics of guard's scope exit by attaching it to other constructs.