Why Rust? [pdf]

Re:Why Rust? [pdf] by tomp on Wednesday September 09, 2015 @03:56PM (#10194066)

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`.

[ Parent | on HN ]

Re:Why Rust? [pdf] by dllthomas on Wednesday September 09, 2015 @04:40PM (#10194421)

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

[ Parent | on HN ]

Re:Why Rust? [pdf] by tomp on Wednesday September 09, 2015 @05:24PM (#10194726)

> 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?

[ Parent | on HN ]

Re:Why Rust? [pdf] by dllthomas on Wednesday September 09, 2015 @07:10PM (#10195269)

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).

[ Parent | on HN ]