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 <mailto: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 <mailto: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
>>> <https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9>
>>>
>>> Looking 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
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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
