I second Xiaodi on this. The syntax feels like a slam-dunk. The only concerns I have are indentation, and ultimately that's not my problem to decide about. ;) Sincerely, Zachary Waldowski z...@waldowski.me
On Wed, Jul 5, 2017, at 07:15 PM, Xiaodi Wu via swift-evolution wrote: > 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- >>> evolut...@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- >>>> evolut...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution