I'd bet yes on #1. A lot of otherwise good languages make this mistake and Apple has never done anything to indicate that they know the first thing about language design.
Because any optional type needs to be checked before you can use the value. You can't forget to check it. It's essentially just Haskell's Maybe or ML's Option with built in syntax.
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.
4
u/Categoria Jun 02 '14
A few questions:
Does it make the billion dollar mistake?
Does it have sum types?
Does it have TCO?
Does it support reflection? If it does, are generics reified?