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! could just throw an exception …
regards
Dominik
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 <swift-evolution@swift.org> 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 gracefully recover ;)so how about we do the same as with try/catch where you can use try! and have a guard!
the guard! could just throw an exception …
regards
Dominik
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
We have that; it’s just ‘!’. :-)
Jordan
On May 2, 2016, at 12:09, Dominik Pich via swift-evolution <swift-evolution@swift.org> 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 gracefully recover ;)so how about we do the same as with try/catch where you can use try! and have a guard!
the guard! could just throw an exception …
regards
Dominik
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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 <david@alkaline-solutions.com> 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!.
-DW
On May 2, 2016, at 1:09 PM, Dominik Pich via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 gracefully recover ;)so how about we do the same as with try/catch where you can use try! and have a guard!
the guard! could just throw an exception …
regards
Dominik
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/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, 2016, at 1:38 AM, Jordan Rose <jordan_rose@apple.com> wrote:
We have that; it’s just ‘!’. :-)
Jordan
On May 2, 2016, at 12:09, Dominik Pich via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 gracefully recover ;)so how about we do the same as with try/catch where you can use try! and have a guard!
the guard! could just throw an exception …
regards
Dominik
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/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.
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 callOn May 3, 2016, at 1:38 AM, Jordan Rose <jordan_rose@apple.com> wrote:
We have that; it’s just ‘!’. :-)
Jordan
On May 2, 2016, at 12:09, Dominik Pich via swift-evolution < > swift-evolution@swift.org> 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 gracefully
recover ;)so how about we do the same as with try/catch where you can use try! and
have a guard!the *guard!* could just throw an exception …
regards
Dominik
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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 operator is unsafe. Specifically, a lot of direct property access shouldn’t be done with it because of the fact that even if you check, another thread may come in, switch the variable to “nil” and all of a sudden you have a crash despite your best efforts.
That said, if you properly reason about your code, the ! operator is a useful and reasonable access tool to unwrap the optional you know about.
I certainly don't agree that we need a language construct purely so we can write verbose things as a big scary warning.
On 3 May 2016, at 4:41 PM, 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.
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, 2016, at 1:38 AM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
We have that; it’s just ‘!’. :-)
Jordan
On May 2, 2016, at 12:09, Dominik Pich via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 gracefully recover ;)so how about we do the same as with try/catch where you can use try! and have a guard!
the guard! could just throw an exception …
regards
Dominik
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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 all) using the other type system constructs.
Likewise for all the other postfix-! keywords ('as!', 'try!', etc).
Austin
On May 2, 2016, at 11:53 PM, Rod Brown via swift-evolution <swift-evolution@swift.org> wrote:
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 operator is unsafe. Specifically, a lot of direct property access shouldn’t be done with it because of the fact that even if you check, another thread may come in, switch the variable to “nil” and all of a sudden you have a crash despite your best efforts.
That said, if you properly reason about your code, the ! operator is a useful and reasonable access tool to unwrap the optional you know about.
I certainly don't agree that we need a language construct purely so we can write verbose things as a big scary warning.
On 3 May 2016, at 4:41 PM, Dominik Pich via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
;) 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, 2016, at 1:38 AM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
We have that; it’s just ‘!’. :-)
Jordan
On May 2, 2016, at 12:09, Dominik Pich via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 gracefully recover ;)so how about we do the same as with try/catch where you can use try! and have a guard!
the guard! could just throw an exception …
regards
Dominik
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Very well said.
on Mon May 02 2016, Austin Zheng <swift-evolution@swift.org> 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 that can't otherwise be expressed (cleanly or at all) using the
other type system constructs.
--
Dave