[swift-evolution] [Pitch] Guard/Catch

[Xiaodi Wu]

Initially, this proposal felt a little off, but on re-reading, I think I
like it very much. It shows that guard/catch is meant to solve a nesting
problem (just like guard/else was meant to solve one), and it preserves the
idea that the else/catch clause must exit the outer scope, which is very
important to the meaning of `guard`.

I agree with the proposal authors that mix-and-match guard/catch/else feels
unwise. I see no reason why rewriting to repeat only the word `guard` (as
in, `guard A catch { }; guard B else { }` instead of `guard A, B catch { }
else { }`) is onerous enough to justify a syntax that is clearly harder to
reason about.

On Wed, Jul 5, 2017 at 2:25 PM, Soroush Khanlou via swift-evolution <
swift-evolution at swift.org> wrote:

> Jon — we explored allowing users to mix and match optional unwrapping and
> error catching in the same guard, but found that it was ultimately pretty
> confusing. We think that guard/else and guard/catch should be two totally
> different components. Dave’s email lays out the two best approaches, and
> the “Alternatives Considered” section of the proposal goes into why those
> alternatives were ultimately rejected.
>
> On Jul 5, 2017, at 2:09 PM, Dave DeLong via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Soroush’s proposal has the idea that maybe we could do multiple blocks for
> this scenario, like so:
>
> guard try something(), let thing = optionalThing catch {
>     // try something() failed
> } else {
>     // the let-binding failed
> }
>
> 🤔 Alternatively, what if the “error” captured was optional in this
> scenario?
>
> guard try something(), let thing = optionalThing catch {
>     if let error = error {
>         // the try call failed
>     } else {
>         // the optional binding failed
>     }
> }
>
> Dave
>
> On Jul 5, 2017, at 12:00 PM, Jon Shier via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I didn’t think I was going to like it but I really do. My only concern,
> which isn’t really a deal breaker, is what it would look like to chain
> multiple try and let statement in the same guard. Unless that scenario
> works well I don’t think you could convince others. i.e. In the case where
> I have:
>
> guard try something(), let thing = optionalThing catch { }
>
> What happens when the let fails? No implicit error?
>
>
>
> Jon
>
>
> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I’d like to propose a guard/catch construct to 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.
>
> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9
>
> Looking forward to feedback!
>
> Soroush
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170705/edeebada/attachment.html>