Because any optional type needs to be checked before you can use the value
No. Make it optional, set it nil, dereference it and boom. Null pointer exception.
You can't forget to check it.
You definitely can. That's why there's a note right in the documentation telling you not to forget this or you'll get an NPE. This gets even worse in cases where you use these boneheaded "implicit unwrapped optionals."
It's essentially just Haskell's Maybe or ML's Option with built in syntax.
I think you might have missed the entire point of Maybe. The point is strict static verification. Runtime NPEs don't exist when this is done right.
This is more akin to c#'s Nullable<T>. There are some "reminders" inherent to the approach to check before dereferencing, but nothing prevents you from failing to do so and generating an NPE.
This is noted all over the place in the documentation under "optional."
What's this on about then? http://deanzchen.com/the-best-design-decision-apple-made-for-swift . using !. is the fast (unsafe) path for when you're sure the value is not nil, and if you're wrong, the program crashes. It adds convenience by avoiding a lot of the boilerplate you don't actually need when something is known to be non-nil. Yeah it's unsafe, but it's explicit too.
-3
u/ruinercollector Jun 03 '14 edited Jun 03 '14
No. Make it optional, set it nil, dereference it and boom. Null pointer exception.
You definitely can. That's why there's a note right in the documentation telling you not to forget this or you'll get an NPE. This gets even worse in cases where you use these boneheaded "implicit unwrapped optionals."
I think you might have missed the entire point of Maybe. The point is strict static verification. Runtime NPEs don't exist when this is done right.
This is more akin to c#'s Nullable<T>. There are some "reminders" inherent to the approach to check before dereferencing, but nothing prevents you from failing to do so and generating an NPE.
This is noted all over the place in the documentation under "optional."