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.
Which is why you can do exactly that.
if let checked = blah { /* checked does not need ! or ? */ }guard let foo = optFoo { Swift.print("oops, this optional thing wasn't optional") }
Swift.print("now \(foo) is in scope and non-nil")
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?
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.
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 */ }
I still don't understand the point of ! and ?
less is more, swift ought to know.
You seem to be insisting on using ! and then blaming the language for letting you shoot your foot off with 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 !,
! 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++.
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"
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.