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
[email protected]
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
> <[email protected]> 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-
>>> [email protected]> 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-
>>>> [email protected]> 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
>>>>> <[email protected]> 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
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _________________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
