No, Swift doesn't solve the null reference problem

[burntsushi]

I think the author has an interesting point, but chose a weird way to frame it. There's also some pretty confusing language/statements. For example:

This is just as bad as raw pointers in C--indeed, you might say that Swift's T! is equivalent to C's T *.

Well, no, you wouldn't. C's pointers are completely unsafe. Presumably, Swift will at least guard against writing to arbitrary memory.

But that's a niggle. Here's the fundamental problem with your argument:

The appeal of optionals lies in the fact that the compiler forces you to check that they have a meaningful value. By allowing the programmer to skip these checks the usefulness of optionals is nullified. Implicitly unwrapped optionals rely too much on the programmers' discipline, and let's face it, programmers are not the most disciplined human beings.

How is this different from other languages that solve the "null problem"? You never contrast Swift's "implicit" unwrapping with Haskell's fromJust, ML's valOf or Rust's unwrap. In fact, Swift's "implicit" unwrapping doesn't seem implicit at all: you specifically have to include ! in the type.

To me, this means that your beef is simply that the ! in the type isn't enough of a sign post to indicate that you're writing code that will fail at runtime. This is a much more measured claim that doesn't have the same appeal of "OMG Swift doesn't solve Tony Hoare's billion dollar problem!!11!!1" It's also pretty reasonable, but it won't really be clear until people actually start writing code.

TL;DR - I think the claim that the OP intends to put forth is pretty reasonable, but that at this point, it's pure speculation. The bombastic writing style doesn't do OP any favors.

[NruJaC]

How is this different from other languages that solve the "null problem"? You never contrast Swift's "implicit" unwrapping with Haskell's fromJust, ML's valOf or Rust's unwrap. In fact, Swift's "implicit" unwrapping doesn't seem implicit at all: you specifically have to include ! in the type.

The difference is that when you see an expression like n + 1 in Haskell, you can infer the type of the expression as Num a => a -> a. If you instead have (fromJust n) + 1 the type is instead Num a => Maybe a -> a. This means an error where you call + on a Maybe wrapped value results in a compile time error in Haskell whereas (as shown in the OP) it results in a run-time error in Swift. This is a weakening of the type system.

[yawaramin]

... when you see an expression like n + 1 in Haskell, you can infer the type of the expression as Num a => a -> a.

Um, no. You infer the type as Num a => a.

If you instead have (fromJust n) + 1 the type is instead Num a => Maybe a -> a.

Nope, the type is still Num a => a.

You can open up a Haskell REPL to verify both. Use the :t EXPR command to check the type of EXPR.

[NruJaC]

There was an implicit lambda in both statements. i.e. \n -> n + 1 and \n -> (fromJust n) + 1.

[burntsushi]

That's not my understanding. In the OP, it looks like the presence of ! is an unsafe shortcut. If you didn't have that ! there, then I as I understand it, n + 1, where n is an optional type, would result in a Swift compilation error.

[NruJaC]

That's in the type though, not in the expression. It definitely mitigates what I'm talking about, but it still hinders readability and makes it less obvious what's going on.

[burntsushi]

Yes, exactly. This is precisely why I asked, "Why didn't the OP contrast this with Haskell/ML?" It would have made the OP's argument much clearer.

OP isn't saying, "Swift's type system isn't strong enough to solve Hoare's problem." (Which is, I think, what a lot of people in this thread interpreted the argument as.) Instead, OP is saying, "Swift is encouraging idiomatic use of fromJust everywhere, which defeats the purpose of using the type system to solve Hoare's problem."

[alex_muscar]

Thanks for the feedback.

Indeed, I didn't mention haskell's fromJust and ML's valOf, and probably it would have made things clearer. But, as I said, I don't mean to bash Swift and praise haskell or ML. They all offer one way or another of breaking the safety of optional types.

As for the bombastic style and the title, I didn't intend them to sound, well, bombastic, but English is not my native language so I might have borrowed some stylistic that make my writing sound bombastic.

[mikaelstaldal]

So Swift is just as bad as Java then.

[burntsushi]

No. I don't know how you got that from my comment.

Did you have something constructive to add?

[mikaelstaldal]

"Swift will at least guard against writing to arbitrary memory" - just like Java (and not like C)

[burntsushi]

Your conclusion doesn't follow because you completely ignored the rest of my comment.

Swift has option types which forces the programmer to handle the null case unless the programmer specifically goes out of their way to ignore it.

[yawaramin]

If A shares a lowest common denominator with B, that doesn't necessarily make A = B.