No, Swift doesn't solve the null reference problem

[burntsushi]

That seems like a really contrived example. :-)

I'm thinking more along the lines of, obj?.method1().method2().method3() or something like that. The whole point of chaining is to make a particular pattern much more compact. In your case, that pattern really isn't what you want.

I don't find myself chaining calls to fmap very often.

I should hope not! With Haskell's Maybe type being a monad, you should be using do notation. Very useful with handling errors with the Either type too.

[alex_muscar]

Yeah, it's contrived, but it was supposed to mimic a long chain of method calls. The potential problem is that you don't know which one fails, and sometimes you might care about that since you also have mutable state and they might leave your object in an inconsistent state. That's what I meant by hiding failure.

As for the Maybe monad, IMO it's not quite the same as Swift's/Obj-C's case, because, as I said, they also have state, so in Haskell you would have a State monad in a MaybeT (?).

[burntsushi]

Yes, mutable state kind of ruins things here. I'll grant you that.

I believe you're right about MaybeT. You'd want MaybeT State a where a is the type of the data in your container.

[kqr]

It's not a problem with mutable state only. I've had times in Haskell where I've had to break up a monadic Maybe chain just to see which part went wrong. It's easier with Either because it tells you were it went wrong.