Amazing proposal, I love it and thinking back there's plenty of times where I would have used the guard-catch instead of the non-swifty (to me) do-catch. A guard-catch construct still allows to handle errors explicitly, with the added convenience of forcing a return inside the catch, which is basically 100% of the cases for me. It's consistent with the semantics of "guard", that is, instead of indenting, exit the scope in the "negative" case.
I do not agree in mixing guard-catch with optional binding (+ bool conditions). I think it's clearer to keep the two separated, since you can always:
guard let x = try throwingFunction() catch { ... }
guard let y = x.optionalProperty, y == 42 else { ... }
Thanks
Elviro
···
Il giorno 05 lug 2017, alle ore 19:40, Soroush Khanlou via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> ha scritto:
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:
guard-catch.md · GitHubLooking forward to feedback!
Soroush
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution