Hm... not really.

Say you have a function, `f : (bool, T) -> Option<T>`.

    function f<T>(cond : bool, value : T) : Option<T> {
      if cond {
        return value                 // equivalent: Some(value)
      } else {
        return null                  // equivalent: None
      }
    }

    let x = f(false, f(false, 1))    // equivalent: None
    let y = f(true, f(false, 1))     // equivalent: Some(None)

There is no way to tell apart `x` and `y`.

You are confusing types and representations, and your function is not well typed.

> You are confusing types and representations

Hm... not sure if I am. Or, at least, `null or T` is not a valid representation for type `Option<T>`. It's all very confusing.

> and your function is not well typed.

How so?

The `value` you are returning has type T. T is not the same type as Optional<T>.

With AnimalMuppet's approach, you would need to return a pointer to a T (so, `&value` in something Cish). Note that this is not the same thing as a nullable reference in, for instance, C#.

`null or T` is a valid representation only when T is a non-nullable reference. It doesn't work when T is optional, and it also doesn't work when T is a primitive type, a struct, &c.

That said, there's obvious reasons it might be wanted an optimization where it's possible. For that specific case, `Just value` could be specialized to `value`, but that can be done by the compiler (akin to automatic unboxing, elsewhere).

Yeah, I'm curious about this too. It seems like (continuing to use Rust parlance) your three examples are (respectively) `None`, `Some(None)`, and `Some(Some(some value of interest))`. There is no `None(None)` case, so there's no problem.

This is fair. I was thinking of this in the context of GC'd languages, where one instead has nullable types (or sentinel null values). Eg. Java, C#, Python, Ruby, Scala.

The C++ case where a distinction between `foo = null` and `*foo = null` exists is indeed much closer to a an option type. You're right to point it out.