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