[swift-evolution] [Pitch] Guard/Catch

[Zach Waldowski]

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
  zach at 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 at 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-
>>> 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> 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> 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 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
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> 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
>> 
> _________________________________________________
> 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/a1777bfc/attachment.html>