Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-03 Thread Dave Abrahams via swift-evolution
on Mon May 02 2016, Austin Zheng wrote: > +1. The force unwrap operator is basically a runtime assert that enforces the > invariant that "this value should not be nil at this point of use, and if it > is > nil the programmer made a mistake". It is a perfectly legitimate tool for > writing code

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread Austin Zheng via swift-evolution
+1. The force unwrap operator is basically a runtime assert that enforces the invariant that "this value should not be nil at this point of use, and if it is nil the programmer made a mistake". It is a perfectly legitimate tool for writing code that can't otherwise be expressed (cleanly or at al

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread Rod Brown via swift-evolution
I’m on the side of the ‘!’ at the moment. I see a lot of heat here going into hatred of the force unwrap operator, as if it should be avoided like the plague. I simply don’t see the need for such absolutism. It’s there for a reason. There are definitely use cases where use of the force unwrap o

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread Xiaodi Wu via swift-evolution
Besides the legacy operator `!=`, isn't virtually every place you see ! potentially fatal, for some definition of potential? ;) On Tue, May 3, 2016 at 01:41 Dominik Pich via swift-evolution < swift-evolution@swift.org> wrote: > ;) yes. I know I can write let x = y! but IMHO THAT is too brief again

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread Dominik Pich via swift-evolution
;) yes. I know I can write let x = y! but IMHO THAT is too brief again. I like the fact that guard makes you look what you do… it is a little bit like assert(x != nil) guard! let x = y it reads awesome and everybody can more easily see it is a potentially fatal & important call > On May 3, 20

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread Jordan Rose via swift-evolution
We have that; it’s just ‘!’. :-) Jordan > On May 2, 2016, at 12:09, Dominik Pich via swift-evolution > wrote: > > Hello, > often the guard statement is used to only unwrap optionals. multiple guards > will cause a lot of ‘overhead’. > also often if it doesn’t work. there is no easy way we can

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread Dominik Pich via swift-evolution
yes. true. that’d be also totally fine. my main issue is to make unwrapping easier ;) > On May 2, 2016, at 9:57 PM, David Waite wrote: > > By existing semantics of the exclamation mark, ‘guard!' would be expected to > cause the application to fail fatally, not throw. This is the same as try!.

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread David Waite via swift-evolution
By existing semantics of the exclamation mark, ‘guard!' would be expected to cause the application to fail fatally, not throw. This is the same as try!. -DW > On May 2, 2016, at 1:09 PM, Dominik Pich via swift-evolution > wrote: > > Hello, > often the guard statement is used to only unwrap op

[swift-evolution] proposal for a even simpler guard.. => guard!

2016-05-02 Thread Dominik Pich via swift-evolution
Hello, often the guard statement is used to only unwrap optionals. multiple guards will cause a lot of ‘overhead’. also often if it doesn’t work. there is no easy way we can gracefully recover ;) so how about we do the same as with try/catch where you can use try! and have a guard! the guard! c