I know you have got a TON of replies demonstrating better ways to check if a value is null or not. I believe they are all missing the point. In a language with monads, Option's should not be part of the function signature unless it is important to the logic of that function. Your given example should look like:

    func1(a: i32, z: i32) -> i32 {
        return a + z
    }

I know it's not 1 to 1, but the idea is there. You would then use a tiny bit of glue code to combine all the stuff you have to get what you want. For example, if you have 2 nullabes as parameters, you use liftM2; if you have 1 nullable, you use liftM; or perhaps you just want reduce a structure, so you reach for foldM. etc. If your monadic code has to constantly figure out what monad it is, you aren't buying yourself much and I could see why you don't find them valuable. And if the function explicitly needs an Option, then it must be important and must be taken into consideration by the caller. I just don't think they should force the caller to consider them where not needed.

I wanted to mention I often see similar statements with almost the identical code comparison that you made. I believe it has to do with retraining oneself to think functionally instead of imperatively. I'm curious about your background.

For good measure, here's another example in Haskell:

    func1 a b = fromMaybe 0 (liftM2 (+) a b)

And an uglier, but fun, point-free version:

    func1 = (fromMaybe 0 .) . liftM2 (+)

I believe real-world examples would hold up better because the glue code would only be where needed.

> Option's should not be part of the function signature unless it is important to the logic of that function.

Yes! Absolutely. Very important observation. In fact in Haskell Maybe should not be part of the signature if you want to return Nothing whenever one of the arguments is Nothing.

> And an uglier, but fun, point-free version

Yikes, please don't! People might get the wrong idea about how good Haskell is written.

In Scala, you can use `for`, although I think your point remains valid for languages without any sort of monad support:

    def func1(q: Option[Int], z: Option[Int]): Int = {
        (for {
            qval <- q
            zval <- z
        } yield q + z).getOrElse(0)
    }

In languages like Haskell and Scala that supports `do` / `for` comprehension sugar, this could be done without the nesting:

  fn :: Maybe Int -> Maybe Int -> Int
  fn q z = fromMaybe 0 $
    do 
      q_in <- q
      z_in <- z
      return (q_in + z_in)

In modern Haskell, we are more likely to use the Applicative instance for Maybe, e.g.

    fromMaybe 0 $ 
        (+) <$> xm <*> ym

Or just:

    fn (Just q) (Just z) = q + z
    fn _ _ = 0

Surely since you have monads you can just use the tools they give you?

    fn = liftM2 (+)

That doesn't do quite the same thing; the original example gets rid of the Maybe, defaulting to 0.

> That doesn't do quite the same thing

You're missing the point entirely.

> the original example gets rid of the Maybe, defaulting to 0.

http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-M...

Wouldn't this let me call `fn true false` or `fn "hi" 2`? Or the second declaration takes the inferred type of the arguments from the first one?

This isn't two functions: it's actually one function defined by cases. You can think of it as equivalent to

    fn x y = case (x, y) of
      (Just q, Just z) -> q + z
      (_, _) -> 0

but the case becomes implicit in the repetition of the function name at the top level of indentation.

> at the top level of indentation

At the same level, really - it works in a let or a where as well.

As those others wrote you would probably use for

I wrote a little bit about how to work with the Future Monad in "A Little Guide on Using Futures for Web Developers'

http://codemonkeyism.com/a-little-guide-on-using-futures-for...

Most languages with monads have tools for working with them. In Haskell, for example, even without `liftM2` or `sequenceM`, you can simply do

    case (xm, ym) of
        (Just x, Just y) -> x + y
        _ -> 0

That's got nothing to do with monads though, you can do that in Swift or Rust which have a monadic option type but don't actually have monads:

    match (xm, ym) {
        (Some(x), Some(y)) => x + y,
        _ => 0
    }

Oh, come on. Is yielding 0 there really the best approach? It's a copout. You want full referential transparency.

In Rust you can also write:

    if let (Some(q_in), Some(z_in)) = (q, z) {
        q_in + z_in
    } else {
        0
    }