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
> <[email protected] <mailto:[email protected]>> 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:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9
> <https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9>
>
> Looking forward to feedback!
>
> Soroush
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
