Re: [swift-evolution] [Pitch] Guard/Catch

case NonFatal(e) => Failure(e) >>> } >>> } >>> } >>> >>> It also would make >>> >>> try startHandler(observer) catch { >>> observer.sendFailed(error) >>> } >>> >>> an ob

Re: [swift-evolution] [Pitch] Guard/Catch

since it’s just treating the >> one function call expression as it’s own implicit do block. >> >> Tyler >> >> >> >>> On Jul 11, 2017, at 10:31 AM, Christopher Kornher via swift-evolution >>> <swift-evolution@swift.org <mailto:swift

Re: [swift-evolution] [Pitch] Guard/Catch

treating the one > function call expression as it’s own implicit do block. > > Tyler > > > >> On Jul 11, 2017, at 10:31 AM, Christopher Kornher via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

Re: [swift-evolution] [Pitch] Guard/Catch

swift-evolution@swift.org> wrote: > > > > Begin forwarded message: > > From: Christopher Kornher <ckorn...@me.com <mailto:ckorn...@me.com>> > Subject: Re: [swift-evolution] [Pitch] Guard/Catch > Date: July 10, 2017 at 5:10:15 PM MDT > To: Elviro Rocca <

Re: [swift-evolution] [Pitch] Guard/Catch

Not sure what you mean here. A guard/catch would allow me to handle the error in the catch, something that (of course) cannot be done with "try?", so guard/else with "try?" is not a solution. And of course returning in the catch side of a do/catch is like returning in the else side of a

Re: [swift-evolution] [Pitch] Guard/Catch

> On Jul 10, 2017, at 1:51 AM, David Hart via swift-evolution > wrote: > > I know we can’t do much about it now, but if optional binding had used the > same syntax as it does in pattern matching, we wouldn’t be having this > discussion: > > guard let x = try

Re: [swift-evolution] [Pitch] Guard/Catch

I don't think that "guard let x? = ..." would be syntactically correct, AFAIK for matching the pattern "let x? =", as for any other pattern, you need to use "case", in fact the following is perfectly valid: guard case let x? = doSomething() else { // handle when nil } I think that "guard

[swift-evolution] [Pitch] Guard/Catch

One of the reasons I like this proposal is at a higher level we are checking for errors and have the ability to exit early if there is an error, I think this aligns well with what `guard` represents, at least to me. Using `try?` effectively ignores the error so if we want convenience we have to

Re: [swift-evolution] [Pitch] Guard/Catch

> On 10 Jul 2017, at 09:45, Elviro Rocca via swift-evolution > wrote: > > This is not a sugar proposal, in the same way as "guard" is not syntactic > sugar, because it requires exiting the scope on the else branch, adding > expressive power and safety to the call:

Re: [swift-evolution] [Pitch] Guard/Catch

This is not a sugar proposal, in the same way as "guard" is not syntactic sugar, because it requires exiting the scope on the else branch, adding expressive power and safety to the call: also, the sugary part is pretty important because it avoids nested parentheses and very clearly states that

Re: [swift-evolution] [Pitch] Guard/Catch

> On Jul 8, 2017, at 3:08 PM, Christopher Kornher via swift-evolution > wrote: > > I am opposed to this proposal because it muddies up the language to support > what is essentially an edge case. The standard way to exit a function early > because an exception is

Re: [swift-evolution] [Pitch] Guard/Catch

I dashed these emails off very quickly, which is something I should never do here. There problems with the “trailing catch” idea. Some of them could be made to work, with enough rules added, but it would probably have been best to just stick with my original objection to adding special-case

Re: [swift-evolution] [Pitch] Guard/Catch

Thanks for you considerate reply. My concern over the proliferation of “sugar proposals” is a general one. This proposal has more merit and general utiliity than many others. I have never used a throwing function in a guard statement that was not itself in a throwing function, but I can see

Re: [swift-evolution] [Pitch] Guard/Catch

> On Jul 8, 2017, at 4:08 PM, Christopher Kornher wrote: > > I am opposed to this proposal because it muddies up the language to support > what is essentially an edge case. The standard way to exit a function early > because an exception is thrown is to make the function

Re: [swift-evolution] [Pitch] Guard/Catch

I am opposed to this proposal because it muddies up the language to support what is essentially an edge case. The standard way to exit a function early because an exception is thrown is to make the function itself throw, if it is part of a larger operation. The addition of a few lines of

Re: [swift-evolution] [Pitch] Guard/Catch

On Sat, Jul 8, 2017 at 2:11 PM, Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > > func doSomething() throws → Result? { … } > > How would you handle both the catch and the let binding of the result? > > > I agree this proposal needs to define the behavior, since

Re: [swift-evolution] [Pitch] Guard/Catch

> func doSomething() throws → Result? { … } > > How would you handle both the catch and the let binding of the result? I agree this proposal needs to define the behavior, since returning an optional from a throwing function is valid. I see a few options: 1) find a way to generally

Re: [swift-evolution] [Pitch] Guard/Catch

What about the situation where you have: func doSomething() throws → Result? { … } How would you handle both the catch and the let binding of the result? Dave > On Jul 7, 2017, at 7:55 AM, Elviro Rocca via swift-evolution > wrote: > > Amazing proposal, I love it

Re: [swift-evolution] [Pitch] Guard/Catch

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

Re: [swift-evolution] [Pitch] Guard/Catch

Howdy, I love it! The “do" blocks never did “feel” like Swift. I can see how both would be useful. I like to use as many conditionals in a single guard statement as I can get away with, so I was concerned that guard/catch would need to interoperate with guard/else. However, I

Re: [swift-evolution] [Pitch] Guard/Catch

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 z...@waldowski.me On Wed, Jul 5, 2017, at 07:15 PM, Xiaodi Wu via swift-evolution wrote: > Initially,

Re: [swift-evolution] [Pitch] Guard/Catch

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

Re: [swift-evolution] [Pitch] Guard/Catch

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

Re: [swift-evolution] [Pitch] Guard/Catch

> On Jul 5, 2017, at 10:30 AM, Soroush Khanlou via swift-evolution > 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

Re: [swift-evolution] [Pitch] Guard/Catch

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

Re: [swift-evolution] [Pitch] Guard/Catch

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

Re: [swift-evolution] [Pitch] Guard/Catch

Some prior, probably not as well thought-through, discussion on this topic: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011446.html On Wed, Jul 5, 2017 at 10:40 AM Soroush Khanlou via swift-evolution < swift-evolution@swift.org> wrote: > I’d like to propose a

[swift-evolution] [Pitch] Guard/Catch

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