6 ms·

I'm porting my app to swift. I started to feel the pain. admittedly I haven't studied the language systematically. the biggest pain I think is the error messag

I'm porting my app to swift. I started to feel the pain. admittedly I haven't studied the language systematically. the biggest pain I think is the error messages. some doesn't make sense. I also don't appreciate the ! and ?. In my opinion, checking whether a variable is null or not is easier than using ? and ! everywhere.

stormbrew 11y ago
> In my opinion, checking whether a variable is null or not is easier than using ? and ! everywhere. Which is why you can do exactly that. if let checked = blah { /* checked does not need ! or ? */ }
- tpritc 11y ago
  You still need to use ! inside that block, but you can use it confidently that it won't result in you accidentally unwrapping a null object.
  - stormbrew 11y ago
    No, you use checked instead of blah. If blah is type 'Blah?', Checked is type 'Blah'. Edit to add: And unless something has changed since I last tried it, you can also just shadow blah so that inside that scope you're referring to the unwrapped one: if let blah = blah { /* use blah here, it's unwrapped */ } It looks kind of silly, but I have used it where there was no better name for the unwrapped value.
    - billconan 11y ago
      this doesn't look better than c++ syntax. I still don't understand the point of ! and ? less is more, swift ought to know.
      - stormbrew 11y ago
        I don't think it's trying to be syntactically better than C++. It's an improvement in semantics. Once you unwrap an optional with "if let", it cannot cause an access violation. You seem to be insisting on using ! and then blaming the language for letting you shoot your foot off with it...
        billconan 11y ago
        Sorry, I don't get it. the example you gave is like the following c++ code: XXX *object = null; if ((object = anotherpointer) != NULL) { ... } The point is, ! is only useful, when it can detect null pointers during compiling time. but it doesn't. the way ! is used, as suggested by your example, is also doable in C++, it is just a habit thing. in c++, with good habit, you won't have problem. in Swift with bad habit, you will have the same problem. then what good is !,
        stormbrew 11y ago
        No, you don't seem to be getting what I'm saying. I'm saying don't use !, and showing you how to avoid using it in a common pattern. Using 'if let' instead of ! does give you compile time verification of correctness. ! is there for the small number of cases where that's not possible. And it makes it much more obvious where you've got a potential problem, because the '!' is a literal code smell. You can't really do that with c++.
        yoz-y 11y ago
        Ever since the guard statement was introduced I think you should never, ever use the ! as operator. It still has some sense when using as a type, for example for IBOutlets.
- billconan 11y ago
  I'm curious, if my variable "a" is indeed null, and when I say a!, what will happen? will it be a runtime error? like a memory access violation in c++? what's the benefit of adding !? if it generates the same access violation runtime error?
  - rockshassa 11y ago
    yes, it is a runtime error. given the code let foo = bar! If bar is nil, you'll get a runtime error "unexpectedly found nil when unwrapping bar" in my opinion, the benefit of optionals in general is that it allows you to guarantee at compile time that certain variables (non optionals) will _never_ be nil, which enables all kinds of compiler optimizations.
- sulam 11y ago
  Arguably the newly supported guard syntax is nicer: guard let foo = optFoo { Swift.print("oops, this optional thing wasn't optional") } Swift.print("now \(foo) is in scope and non-nil")
yoz-y 11y ago
There are _very_ few cases in which you should use the ! operator and all of them are tied to Interface Builder and non-finalized Obj-C APIs. Just use the if let construct or guards.
- billconan 11y ago
  here is a case that I have to use !, maybe I'm using it wrong, please correct me. so I have this "member" in a class class XXX: UIView { var member: BBB init() { super.init() self.member = BBB(self.frame) } } if I do this, I got the error that self.member is not initialized before super.init if I move it to before super.init, self.frame isn't available. my solution to this chicken-egg thing is putting a ? after "member"
  - deleted 11y ago
    [deleted]
  - cballard 11y ago
    let member = BBB() init() { super.init() member.frame = self.frame } ? Note that since this is a UIView subclass, you're actually implementing init(frame:) and init?(coder:), not init(). I usually unify the two by declaring subviews as lets and initializing them in a private setup method.
  - stormbrew 11y ago
    While someone replied with a solution to this problem that may work for you, I will say that I do find the rigidity around initializers frustrating.

stormbrew 11y ago

> In my opinion, checking whether a variable is null or not is easier than using ? and ! everywhere. Which is why you can do exactly that. if let checked = blah { /* checked does not need ! or ? */ }

tpritc 11y ago
You still need to use ! inside that block, but you can use it confidently that it won't result in you accidentally unwrapping a null object.
- stormbrew 11y ago
  No, you use checked instead of blah. If blah is type 'Blah?', Checked is type 'Blah'. Edit to add: And unless something has changed since I last tried it, you can also just shadow blah so that inside that scope you're referring to the unwrapped one: if let blah = blah { /* use blah here, it's unwrapped */ } It looks kind of silly, but I have used it where there was no better name for the unwrapped value.
  - billconan 11y ago
    this doesn't look better than c++ syntax. I still don't understand the point of ! and ? less is more, swift ought to know.
    - stormbrew 11y ago
      I don't think it's trying to be syntactically better than C++. It's an improvement in semantics. Once you unwrap an optional with "if let", it cannot cause an access violation. You seem to be insisting on using ! and then blaming the language for letting you shoot your foot off with it...
      - billconan 11y ago
        Sorry, I don't get it. the example you gave is like the following c++ code: XXX *object = null; if ((object = anotherpointer) != NULL) { ... } The point is, ! is only useful, when it can detect null pointers during compiling time. but it doesn't. the way ! is used, as suggested by your example, is also doable in C++, it is just a habit thing. in c++, with good habit, you won't have problem. in Swift with bad habit, you will have the same problem. then what good is !,
        stormbrew 11y ago
        No, you don't seem to be getting what I'm saying. I'm saying don't use !, and showing you how to avoid using it in a common pattern. Using 'if let' instead of ! does give you compile time verification of correctness. ! is there for the small number of cases where that's not possible. And it makes it much more obvious where you've got a potential problem, because the '!' is a literal code smell. You can't really do that with c++.
        yoz-y 11y ago
        Ever since the guard statement was introduced I think you should never, ever use the ! as operator. It still has some sense when using as a type, for example for IBOutlets.
billconan 11y ago
I'm curious, if my variable "a" is indeed null, and when I say a!, what will happen? will it be a runtime error? like a memory access violation in c++? what's the benefit of adding !? if it generates the same access violation runtime error?
- rockshassa 11y ago
  yes, it is a runtime error. given the code let foo = bar! If bar is nil, you'll get a runtime error "unexpectedly found nil when unwrapping bar" in my opinion, the benefit of optionals in general is that it allows you to guarantee at compile time that certain variables (non optionals) will _never_ be nil, which enables all kinds of compiler optimizations.
sulam 11y ago
Arguably the newly supported guard syntax is nicer: guard let foo = optFoo { Swift.print("oops, this optional thing wasn't optional") } Swift.print("now \(foo) is in scope and non-nil")

yoz-y 11y ago

There are _very_ few cases in which you should use the ! operator and all of them are tied to Interface Builder and non-finalized Obj-C APIs. Just use the if let construct or guards.

billconan 11y ago
here is a case that I have to use !, maybe I'm using it wrong, please correct me. so I have this "member" in a class class XXX: UIView { var member: BBB init() { super.init() self.member = BBB(self.frame) } } if I do this, I got the error that self.member is not initialized before super.init if I move it to before super.init, self.frame isn't available. my solution to this chicken-egg thing is putting a ? after "member"
- deleted 11y ago
  [deleted]
- cballard 11y ago
  let member = BBB() init() { super.init() member.frame = self.frame } ? Note that since this is a UIView subclass, you're actually implementing init(frame:) and init?(coder:), not init(). I usually unify the two by declaring subviews as lets and initializing them in a private setup method.
- stormbrew 11y ago
  While someone replied with a solution to this problem that may work for you, I will say that I do find the rigidity around initializers frustrating.