[swift-evolution] [Pitch] Guard/Catch

[Soroush Khanlou]

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 <mailto: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 <mailto: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 <https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9>
>>> 
>>> Looking forward to feedback!
>>> 
>>> Soroush
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/07e210e2/attachment.html>