Except for the "therefore Obj-C is superior" part, I agree that Option types in languages such as Swift and Scala are unfortunately marred by those languages' need to be compatible with Obj-C and Java, respectively.
I understand idiomatic Scala won't use null, just as I assume idiomatic Swift won't use nil, but nevertheless the fact that they allow nulls weakens their type systems.
Can you explain more about what you mean by Swift allowing nil weakening it's type system? Swift types don't allow nil but you can use a different type that is the optional counterpart. This is just the same as using the Maybe monad in Haskell and can be reimplemented in that way. Do you think that this also weakens Haskell's type system?
Now if your issue was with the "!" Operator I would say that there is a case to be made but that should be used sparingly and carefully and is an obvious place for additional code review.
Hmm, maybe Swift's Optional works differently to Scala's Option, in which case my objection can be dismissed.
In Scala, you can declare a value to be of type Option[T], which means it will be either a Some[T] or a None. This looks superficially like Haskell's Maybe monad.
val x: Option[Int] = Some(1)
The problem with Scala is that you can also write something like this:
val x: Option[Int] = null
By declaring a value to be of type Option[T], you "promise" it won't be null, but this is not enforced by the compiler. It's obvious this is a huge difference from Haskell's Maybe, and it weakens Scala. Null shouldn't even be part of Scala, but it's still there to retain compatibility with Java.
Can a similar example be written with Swift? I assumed it was possible, but maybe I'm mistaken.
In Swift nil is the value equivalent to Haskell's None so there is no distinction there which I think you are saying that there is in Scala.
Swift does have "implicitly unwrapped optionals" which you declare with "!":
var x:Int! = nil
rather than normal optional syntax of
var x:Int? = nil
It does weaken the type system and I would only make very limited use of it. I would only ever use it for properties that will not be nil after the initialiser has finished. Even though there is a way around the type system to do dangerous things I think it is still far better to have the type system there and to only work round it when absolutely necessary than to default to something much weaker. As I've mentioned elsewhere "!" is a code smell and I would use it rarely and audit those places heavily.
That's one of the benefits of Rust imho - no legacy baggage. One of its downsides as well - no ecosystem to draw from. Oh well, take the good with the bad I guess.
I understand idiomatic Scala won't use null, just as I assume idiomatic Swift won't use nil, but nevertheless the fact that they allow nulls weakens their type systems.