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
+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
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
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
;) 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
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
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!.
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
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